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Abstract 


In  this  methodology,  programming  problems  which  can  be  specified  by  an 
input/output  assertion  pair  are  solved  in  two  steps: 

(1)  Refinement  of  a  correct  program  that  can  be  implemented  sequentially. 

(2)  Declaration  of  program  properties,  "semantic  relations",  that  allow  relaxa¬ 
tions  in  the  sequencing  of  the  refinement’s  operations  (e.g.,  concurrency). 

Formal  properties  of  refinements  comprise  semantics  (input/output 
characteristics)  and  (sequential)  execution  time.  Declarations  of  semantic  rela¬ 
tions  preserve  the  semantics  but  may  improve  the  execution  time  of  a 
refinement.  The  consequences  are: 

(a)  The  concurrency  in  a  program  is  deduced  from  its  formal  semantics. 
Semantic  correctness  is  not  based  on  concur  rency  but  precedes  it. 

(b)  Concurrency  is  a  property  not  of  programs  but  of  executions.  Programs  do 
not  contain  concurrent  commands,  only  suggestions  (declarations)  of  con¬ 
currency. 

(c)  The  declaration  of  too  much  concurrency  is  impossible.  Programs  do  not 
contain  primitives  for  synchronization  or  mutual  exclusion. 
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Introduction 


1.1  Concepts  of  Concurrent  Programs 

The  last  decade  has  brought  considerable  advances  in  the  field  of  program¬ 
ming  methodology,  in  general,  and  in  the  understanding  of  concurrency,  in  par¬ 
ticular. 

The  popular  technique  for  programming  concurrency  is  to  define  a  set  of 
concurrent  units,  processes,  and  to  control  their  interaction  by  some  means  of 
synchronization.  The  early  language  constructs  proposed  in  the  sixties,  fork  and 
join  for  processes  [Con63]  and  semaphores  for  synchronization  [Dij68],  were 
intuitive  but  difficult  to  formalize.  However,  the  invention  of  formal  methods  for 
the  specification  of  program  semantics  [Hoa69]  increased  our  understanding 
and  ability  to  handle  process  programs. 

We  commence  the  program  development  by  specifying,  in  a  concurrent 
command,  a  set  of  processes,  SI  ,S2,...,Sn  , 

cobegin  SI  //  S2  //...//  Sn  coend 

which  are  sequential  within  themselves  but  are  executed  in  concurrence  with 
respect  to  each  other.  The  double  slashes  {//)  signify  concurrent  execution.  To 
prevent  concurrency  where  it  may  lead  to  incorrect  program  behaviours,  we  add 
some  construct  for  conditional  delay.  Hor  instance, 

await  <  B  -»  SL  > 

appearing  in  process  Si  suspends  the  execution  of  Si  until  logical  condition  B  is 
satisfied.  Typically,  B  will  be  generated  by  some  concurrent  process  Sj,  j*i. 
Upon  validation  of  B,  the  execution  of  Si  proceeds  with  statement  list  SL.  While 
SL  is  being  executed,  any  concurrent  operation  that  might  cause  correctness 
problems  (for  example,  invalidate  R  again)  is  suspended.  The  technique  of  forc¬ 
ing  activities  of  different  concurrent  processes  into  a  sequence  in  order  to 
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preserve  correctness  is  called  mutual  exclusion.  To  protect  statement  S'  by 
mutual  exclusion,  it  is  framed  with  angle  brackets: 

<  S  > 

These  constructs  for  programming  with  processes  (the  concurrent  com¬ 
mand,  conditional  delay,  and  mutual  exclusion)  can  be  formally  defined 
[0wGr76a,  Lam77],  and  we  can  convince  ourselves  of  the  correctness  of  a  pro¬ 
cess  program  by 

(a)  first  verifying  all  processes  separately  as  if  they  were  isolated  sequential 

programs,  and  then 

(b)  proving  the  correctness  of  their  interactions  in  concurrent  execution. 

A  good  example  is  the  proof  of  a  concurrent  garbage  collector  [Gri77]. 

There  are,  of  course,  problems  and  the  one  we  are  particularly  concerned 
with  in  this  thesis  is  the  apparent  lack  of  guidelines  or  criteria  to  aid  the  pro¬ 
gram  design.  A  proof  system  alone  does  not  necessarily  provide  support  for  the 
development  of  correct  programs.  We  might  continually  produce  code  and  dis¬ 
cover  that  it  is  incorrect.  Wrhat  we  need  is  a  methodology,  a  programming  cal¬ 
culus  that  merges  program  design  and  verification  in  order  to  obtain  correct 
and,  maybe,  even  particularly  suitable  programs. 

Let  us  explain  why  the  approach  to  concurrency  just  described  does  not 
serve  as  a  methodology  for  progr  am  development: 

There  are  no  guidelines  for  the  choice  of  processes.  But  even  if  there  were, 
dividing  a  program  into  processes  is  a  bold  first  step,  because  it  usually  defines 
too  much  concurrency,  which  then  has  to  be  properly  pruned  with  conditional 
delays  and  mutual  exclusion.  Failure  to  undo  all  incorrect  concurrency  leaves 
one  with  an  incorrect  program.  Unfortunately,  parallel  correctness  can  only  be 
established  after  the  development  of  the  processes  involved  has  been  com¬ 
pleted.  Thus  the  development  of  processes  and  the  proof  of  their  correct 
cooperation  are  strictly  separated.  One  has  to  understand  all  process  interac¬ 
tions  in  their  entirety  in  order  to  arrive  at  a  correct  program. 
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Our  goal  is  a  programming  methodology  that  includes  aspects  of  con¬ 
currency.  In  addition  to  a  formally  defined  language  in  which  one  can  communi¬ 
cate  programs  to  the  computer,  we  aim  at  methods  for  a  correct  and  suitable 
stepwise  development  of  such  programs.  In  this  methodology,  concurrency  will 
be  a  property  not  oT  a  program  but  of  an  execution.  If  the  semantic  properties  of 
the  program  permit  concurrency,  an  implementation  should  be  able  to  make 
use  of  it  to  whatever  extent  is  possible  and  practical.  But  the  semantics  will 
determine  the  concurrency,  not  vice  versa.  Then  the  correctness  of  the  program 
does  not  depend  on  our  understanding  of  concurrency.  A  consequence  of  this 
view  is  that  our  programming  language  will  not  contain  primitives  for  sequenc¬ 
ing,  concurrency,  or  synchronization.  These  are  aspects  of  executions,  not  of 
the  program  itself. 

We  will  develop  and  prove  concurrency  in  steps.  Each  step  will  increase  the 
concurrency  of  the  program’s  executions  by  observing  local  properties  of  some 
program  components.  A  global  understanding  ol  the  concurrency  permitted  by 
the  program  is  not  necessary. 

We  will  be  result-oriented,  i.e.,  only  interested  in  results  of  programs  and 
the  speed  writh  which  these  results  can  be  obtained,  but  not  in  certain  program 
behaviours.  Our  programs  will  suggest  suitable  computations  rather  than 
expressing  a  set  of  given  computations.  In  contrast,  process  programs  are 
behaviour-oriented,  i.e.,  designed  with  specific  computations  in  mind. 

A  much-dreaded  sign  of  the  complications  parallelism  introduces  into  pro¬ 
grams  is  that  the  complexity  of  proofs  explodes  with  increasing  concurrency. 
This  is  blamed  on  the  necessity  to  argue  consistency  of  shared  data.  To  prevent 
such  an  argument,  one  can  either  discipline  the  use  of  shared  variables  [Hoa74, 
0wGr76b],  bur,  Thai,  restricts  also  the  potential  of  concurrency.  Or  one  can  elim¬ 
inate  shared  variables  altogether  [GCW79,  Hoa78b],  but  may  in  proofs  still  have 
to  deal  with  shared  auxiliary  variables  [AFROO,  LeGrSl],  Auxiliary  'variables  are 
variables  added  to  a  program  in  order  to  obtain  a  proof  [0wGr76a,  0wGr76bj. 
Our  methodology  uses  shared  variables,  and  subtle  concurrency  may  require  a 
complex  proof.  But  proofs  do  not  contain  auxiliary  variables. 
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There  are  also  the  obstacles  of  deadlock  and  starvation.  Deadlock,  the 
situation  where  the  concurrent  execution  cannot  proceed,  can  occur  in  ter¬ 
minating  as  well  as  non-terminating  applications.  Criteria  for  the  prevention  or 
avoidance  of  deadlock  have  been  investigated  [Holt7S,  Lam77,  0wGr78a, 
0wGr76b].  For  terminating  programs,  total  correctness  implies  absence  of 
deadlock.  Starvation,  the  situation  where  some  action  concurrent  with  others 
can  in  theory  be  activated  but  actually  never  is,  can  only  occur  in  non¬ 
terminating  programs.  To  avoid  starvation  one  often  appeals  to  a  fair  scheduler. 
We  shall  show  that,  under  certain  very  simple  restrictions,  the  generalization 
from  terminating  to  non-terminating  programs  does  not  have  to  pose  additional 
concurrency  problems.  All  programs  derived  with  our  methodology  will  be 
implicitly  free  from  deadlock  and  starvation  without  recourse  to  an  outside 
authority  like  a  scheduler. 


1.2  Devising  a  Methodology 

Our  foremost  interest  is  in  the  result  of  a  program’s  execution,  and  in  the 
constraints  under  which  this  result  can  be  achieved.  In  this  thesis,  we  do  not 
consider  additional  constraints  on  the  program’s  behaviour. 

Consequently,  we  want  to  solve  programming  problems  that  can  be  formally 
specified  by  an  input/output  assertion  pair.  Because  we  are  looking  for  results, 
we  do  not  permit  programs  to  generate  the  false  output  assertion.  This  restricts 
the  range  of  specifiability  to  finite  problems,  i.e.,  problems  that  have  terminat¬ 
ing  solutions  (the  false  output  assertion  indicates  non-termination).  An  infinite 
problem  must  be  expressed  by  a  specifiable  finite  segment  whose  terminating 
solution  can  be  applied  repeatedly. 

Solutions  cannot  contain  event-driven  activities  but  might  be  part  of  a  sys¬ 
tem  with  real-time  constraints.  In  such  a  case  we  may,  in  addition,  specify  exe¬ 
cution  time  requirements. 


The  program  development  consists  of  two  phases: 


(1)  Formal  refinement  of  a  totally  correct  program  that  can  be  implemented 
sequentially. 

We  will  use  methods  that  can,  if  used  correctly,  only  produce  refinements 
whose  semantics  satisfy  the  problem  specification.  The  proof  of  a  refinement 
will  also  yield  a  first  estimate  of  its  execution  time,  namely  a  measure  for  its 
sequential  execution. 

(2)  Declaration  of  program  properties,  so-called  semantic  relations,  that  allow 
relaxations  in  the  sequencing  of  the  refinement’s  operations  (e.g.,  con¬ 
currency). 

We  will  define  semantic  relations  between  refinement  components  and  pro¬ 
vide  rules  for  their  declaration.  Semantic  declarations  will  preserve  the  seman¬ 
tics  of  the  refinement  but  may  suggest  faster  executions,  e.g.,  by  permitting 
concurrency. 

Semantic  declarations  are  a  mechanism  for  the  stepwise  development  of 
concurrency.  They  only  require  a  local  understanding  of  the  refinement  com¬ 
ponents  appearing  in  the  declared  relation.  Remember  that  we  are  interested  in 
outputs,  not  in  program  behaviours.  Accordingly,  we  view  concurrency  as  a  tool 
for  satisfying  execution  time  requirements,  not  for  obtaining  certain  program 
behaviours. 


1.3  The  si  a  Contribution 

There  are  two  different  approaches  to  programming  with  concurrency: 

(a)  consider  a  concurrent  world  in  which  sequentiality  is  the  special  case, 

(b)  consider  a  sequential  world  in  which  concurrency  is  the  special  case. 

We  take  the  latter  view:  we  provide  a  sequential  setting  (refinements)  and 
add  concurrency  (semantic  declarations).  The  refinement  calculus  is  a 
conglomerate  of  ideas  and  concepts  previously  published,  tailored  to  our  needs. 
The  main  contribution  of  this  thesis  is  the  way  in  which  concurrency  in 
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refinements  is  expressed  and  treated. 


1.4  Notation 

We  use  the  logical  operations  A  (and).  V  (or).  ~  (not),  D  (implication),  s 

(equivalence),  and  quantifiers  A  (for  all  i)  and  V  (there  exists  i).  N  denotes  the 

i  i 

natural  numbers,  R  the  real  numbers. 

Program  properties  are  described  in  the  weakest  precondition  calculus. 
The  weakest  precondition  for  statement  S’  with  respect  to  postcondition  R 
(introduced  as  wp (S,R)  in  [Dij75,  Dij 76])  is  here  denoted  S{R].  We  sometimes 
index  statements,  e.g.,  S^de*  or  assertions,  e.g.,  R index-  The  subscripted  weakest 
precondition  is  written  S{R] index  -  Carefully  distinguish  S  [R  jmdex.  index } .  and 

w  ZD  )  t 
^  index  S  • 

Rp  is  predicate  R  with  every  free  occurrence  of  variable  x  replaced  by 

expression  E.  R&  " J1  is  R  with  the  free  occurrences  of  all  xk  simultaneously 
replaced  by  the  corresponding  Ek. 

We  will  treat  an  array  of  variables  as  a  (partial)  function.  Given  a  function 

/,  ( )  is  a  function  as  /,  except  that  it  maps  i  on  v.  ( f\H . in:v1  ,...,vn)  is 

as  /,  except  that  the  images  of  all  ik  are  simultaneously  redefined  as  the 
corresponding  vk.  (For  more  details  see  [Gri78,  GrLeBO].) 

SL is  statement  list  SL  with  every  occurrence  of  statement  5*  replaced  by 
statement  S'. 


1.5  Thesis  Outline 

Chapter  2  gives  an  informal  introduction  to  our  methodology  and  presents  a 
first  programming  example. 
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Chapters  3  to  6  build  the  core  of  the  thesis.  They  deal  with  the  formal 
details  of  the  methodology  and  its  programming  language  RL  (for  Refinement 
Language),  and  demonstrate  them  on  the  same  programming  example.  A 
reader  who  wants  to  gain  only  a  quick  impression  of  our  research  may  skip  these 
four  chapters  and  will  still  understand  most  of  chapters  7  and  8. 

Chapter  3  introduces  the  formal  specification  of  the  programming  problems 
the  methodology  aims  to  solve.  RL  programs  have  to  exhibit  formal  properties 
which  meet  the  specification.  There  are  two  aspects  to  these  properties:  seman¬ 
tics  (input/output  characteristics)  and  execution  time. 

Chapter  4  introduces  a  preliminary  proof  system  for  the  development  of  RL 
programs,  the  refinement  proof  system.  It  is  powerful  enough  to  aid  the  pro¬ 
grammer  in  the  discovery  of  a  solution  to  the  semantic  part  of  the  problem 
specification.  The  refinement  proof  system  describes 

(1)  the  properties  of  a  refinement,  namely  its  semantics  and  (sequential)  exe¬ 
cution  time,  and 

(2)  semantic  properties  of  parts  of  the  refinement,  properties  that  will  suggest 
computations  whoso  semantics  arc  those  of  the  refinement  but  whose  exe¬ 
cution  times  may  be  different. 

The  refinement  proof  system  deals  with  refinements,  not  with  computa¬ 
tions.  It  can  provide  an  execution  time  for  refinements,  but  not  for  computa¬ 
tions. 

If  the  refinement’s  (sequential)  execution  time  is  not  sufficient,  a  more 
detailed  proof  system,  the  trace  proof  system,  has  to  be  employed.  This  is  the 
realm  of  Chapter  f>.  The  trace  proof  system  describes  computations,  so-called 
"traces",  as  opposed  to  programs,  and  serves  to  verify  that  there  are  traces  that 
have  the  refinement’s  semantics  but  arc  sufficiently  fast. 

RL  programs  (described  by  the  refinement  proof  system)  provide  algo¬ 
rithmic  options.  Traces  (described  by  the  trace  proof  system)  reflect  algo¬ 
rithmic  decisions. 

Chapter  6  comments  on  the  implementation  of  RL  programs.  The  central 
problem  is  the  selection  of  a  satisfactory  trace. 


The  remaining  chapters  are  again  less  formal. 

Chapter  7  presents  a  collection  of  further  examples.  Each  makes  some 
point  about  the  methodology.  For  the  readers  of  chapters  3  to  6,  a  formal  treat¬ 
ment  is  provided  in  Appendix  A. 

Finally,  Chapter  8  reviews  the  flavour  of  our  methodology  and  relates  it  to 
previous  work  in  the  area,  describes  directions  for  further  research,  and  adds 
some  general  comments  on  the  use  of  programming  methodologies. 
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2  Careful  Programming  with  Concurrency: 

An  Informal  Presentation 


This  chapter  gives  an  informal  introduction  to  the  methodology  and 
presents  a  first  programming  example. 


2.1  Refinement 

The  first  step  of  the  program  development  is  the  derivation  of  a  refinement 
from  the  input/output  assertion  pair  that  specifies  the  problem. 

We  use  a  special  language,  RL  (Refinement  Language),  for  this  purpose.  RL 
is  closely  related  to  the  refinement  language  of  [lleh?9].  Its  central  feature  is  a 
primitive  procedure  concept,  which  can  be  implemented  efficiently  enough  to  be 
used  extensively  as  a  refinement  mechanism. 

Statements  in  RL  can  either  be  refined,  or  basic  (not  refined).  A  refined 
statement  is  an  invented  name,  say  S'.  Its  meaning  is  conveyed  by  a  refinement, 
S:SL,  relating  the  name  S’  to  a  refinement  body  SL.  Refinements  may  be 
"indexed”,  e.g.,  Sj :  SL  ,  where  index  j  is  a  variable  referenced  in  SL.  An  index  is 
a  primitive  form  of  value  parameter:  j  may  not  be  changed  by  SL. 

In  practice,  indices  will  have  to  be  identified  by  an  index  declaration  in  the 
refinement,  c.g.,  Sj  {j:  int):  SL,  where  SL  refers  to  j.  But,  for  the  sake  of  brev¬ 
ity,  RL  does  not  contain  a  mechanism  for  data  declarations.  We  will  identify 
indices  as  parts  of  the  refinement  name  that  appear  in  its  body. 

There  are  four  options  of  refinement;  we  call  them  refinement  rules:  con¬ 
tinuance,  replacement,  divide  (and  conquer),  and  case  analysis.  Each 
refinement  rule  employs  a  different  programming  feature:  null,  assignment, 
statement  composition,  or  alternation.  Divide  (and  conquer)  and  case  analysis 
employ  a  fifth  programming  feature:  the  refinement  call.  Null  and  assignment 
are  the  basic  (not  refined)  statements  of  RL. 
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(a)  continuance:  S’ :  skip  (null) 

skip  does  nothing  at  all. 

(b)  replacement:  5:  x:=E  (assignment) 

x:—E  gives  variable  x  the  value  of  expression  E . 

(c)  divide-in-2:  5:  S1;S2  (composition) 

SI  ;  S2  applies  statement  S2  to  the  results  of  statement  SI . 

A  divide-in-n  comprises  n  —  1  divide-in-2  in  one  refinement  step.  A  spe- 

n 

cial  case  of  divide-in-n  is  the  for  loop.  We  have  a  special  notation:  ;  Si 

i=i 

stands  for  SI  Sn  J 

(d)  case  analysis:  S:  if  B1  ->  SI  fl  ...  |  Bn-*  Sn  fi  (alternation) 

The  construct  Bi->  Si  is  called  a  guarded  command  [Dij75,  Dij76]. 
Logical  expression  Bi  is  guard  for  alternative  Si.  The  alternative  whose 
guard  evaluates  to  true  is  selected.  We  restrict  case  analysis  to  be  deter¬ 
ministic:  no  two  guards  of  an  alternation  mav  be  true  at  the  same  Lime. 

We  write  if  B  then  S'  G  for  if  B  -*■  S  [j  -*■  skip  fi  . 

Note  the  absence  of  a  popular  language  feature:  indefinite  repetition.  Itera¬ 
tive  algorithms  are  formulated  as  recursive  refinements  or,  in  simple  cases,  by 
for-composition.  While  our  preference  of  recursion  over  repetition  is  not  essen¬ 
tial  for  the  methodology,  the  concept  of  refinement  is. 


2.2  Concurrency 

The  second  step  of  the  program  development  is  the  declaration  of  semantic 
relations  between  parts  of  the  refinement.  Semantic  relations  may  allow  relaxa¬ 
tions  in  the  sequencing  of  the  refinement’s  operations.  The  purpose  of  their 

^  The  loop  bounds  must  be  constants  in  the  loop  scope,  i  is  a  constant  for  every  step  Si 
and  local  to  the  loop. 
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declaration  is  to  speed  up  the  refinement’s  execution,  e.g.,  by  concurrency. 

It  is  important  to  realize  that,  while  this  step  may  improve  the  execution 
time  of  a  solution,  it  is  not  going  to  change  or  add  to  its  semantics.  Semantic 
declarations  only  make  certain  semantic  properties,  which  are  already  laid 
down  in  the  refinement,  more  apparent. 


2.2.1  Semantic  Relations 

Semantic  relations  between  parts  of  a  refinement  indicate  possible  relaxa¬ 
tions  in  sequencing  such  that  its  semantics  are  preserved. 

We  introduce  one  unary  and  four  binary  relations  for  refinement  com¬ 
ponents.  The  unary  relation  is  idempotence;  the  binary  relations  are  commuta¬ 
tivity,  full  commutativity,  non-interference,  and  independence.  Refinement 
components  are  either  statements  or  guards.  Components  in  general  are 
denoted  with  the  letter  C  ,  statements  in  particular  with  S,  and  guards  with  B. 
This  section  gives  only  an  informal  characterization  of  semantic  relations.  The 
precise  definitions  are  in  Sect.  4.3.1. 

(a)  idempotence 

f  B  always 

!S  iff  5 ;  S'  has  the  same  effect  as  S' 

An  idempotent  component  C  may  be  applied  consecutively  any 
number  of  times. 

(b)  commutativity 

R12cB2  always 

S  2c  B  iff  5  leaves  B  invariant 

S1&S2  iff  SI  \S2  has  the  same  effect  as  S2  ;  SI 

Commutative  components  Cl  and  C2  may  be  applied  in  any  order:  C2 


following  Cl ,  or  vice  versa. 
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(c)  full  commutativity 

Cl  3  C2  iff  cl  &c2  for  all  basic  components  cl  in  Cl  and  c2  in  C2 

Full  commutativity  is  commutativity  rippled  down  the  refinement 
structure.  The  execution  of  fully  commutative  components  Cl  and  C2  may 
be  interleaved.  Only  their  basic  operations  must  be  indivisible. 

(d)  non-interference 

Cl  <-|->  C2  iff  every  basic  component  of  Cl  or  C2  gets  no  more  than  one 

view  or  update  of  the  set  of  data  shared  by  Cl  and  C2. 

The  non-interference  of  components  Cl  and  C2  lifts  the  mutual  exclu¬ 
sions,  i.e.,  permits  the  divisibility  of  their  basic  components  (assignment 
and  guard  evaluation). 

(e)  independence 

Cl  ||  C2  iff  Cl  £  C2  A  Cl  C2 

Independence  combines  full  commutativity  with  non-interference. 
Independent  components  Cl  and  C2  may  be  executed  in  parallel  (on 
machines  with  indivisible  memory  reference). 


Examples: 

r 

(1)  5:  x:=3 ,  !S 

(2)  S:  x:=y  ,  B:x= 3,  ~(S&B),  S<^B 

(3)  S1:y:  =  x  + 1,  S2:x:  =  3,  ~(S1&S2),  S1*\+S2 

(4)  S :  t:=p  ;p  :=q :  q  :  =  t  ,  B :  p\r'q  ,  S&B,  ~(S&B),  ~ 

(5)  SI  :  t  :=i- =  t ;  t  +  ,  S2:j:=i,  S1&S2, 

(6)  SI  :  x:=z  +  a  ,  S2:z:  =  x',-b,  S1XS2,  ~(S1<\>S2) 

(7)  S:  c  :=F  ,  B:  aAb  ,  S\\B 

(8)  S1:u:=/(vj),  S2:v:=g(w),  5‘7|{5’2 


(S  +  B) 

~(S1  ZS2),  Sr  4+S2 


Most  independence  relations  will  be  evident  from  the  following 
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Independence  Theorem: 

Two  components  Cl  and  CZ  of  which  neither  changes  any  variables 
appearing  in  both  can  be  declared  independent  (proof  in  Sect.  4.3.  l). 

All  independence  relations  declared  in  programming  examples  of  this  thesis 
are  applications  of  the  independence  theorem. 


2.2.2  Semantic  Declarations 

A  semantic  relation  is  declared  by  stating  the  relation  either  after  a 
refinement,  or  within  a  refinement  by  replacing  the  composition  operator 
with  the  appropriate  relational  operator  (in-line  declaration).  Relational  opera¬ 
tors  bind  stronger  than  We  will  only  declare  idempotence,  commutativity, 
and  independence. 

Relations  that  hold  always,  such  as  between  guards,  do  not  have  to  be 
declared.  To  this  category  belong  also  relations  involving  skip,  and  relations 
between  51  and  ~B  if  already  declared  between  5  and  B  (see  Sect.  4.3.1).  There¬ 
fore  the  hidden  guarded  command  ~B  -»  skip  in  if  B  then  S'  fi  can  be 
neglected  for  semantic  declarations,  for  loop  index  calculations  can  also  be 
ignored. 

A  set  (or  complex)  declaration,  e.g. 

\S1,S2]  H  \T1,TZ\ 

comprises  declarations  between  all  set  members,  in  this  case, 

S1\\T1,  S1\\T2,  S2\\T1,  S2\\TZ 

A  predicate  qualifying  the  range  of  refinement  index  values  may  be  used  to 
define  the  sets  involved.  For  example, 

A  pred  ( i,j ) :  Si  |  j  Sj 
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stands  for  the  set  of  declarations  Si\\Sj  such  that  i  and  j  satisfy  pred(i,j) .  A 
set  index  in  a  complex  declaration  is  passed  on  to  all  set  members.  Assume,  for 
instance,  the  independence  of  turn  signals  of  different  cars  in  a  traffic  system:  if 
we  give  the  operations  of  the  left  and  right  turn  signals  of  car  i  the  names  left * 
and  righti,  we  will  declare 

A  i*j :  [left, right  1*  jj  [left, right  }-• 

ij 

Semantic  declarations  define  additional  computations  for  the  refinement 
they  augment.  Computations  may  contain  statements  and  guards  with  — >  as 
sequencing  operator.  We  will  at  this  point  say  no  more  about  the  structure  of 
computations  and  only  give  a  vague  idea  of  the  effect  of  semantic  declarations 
(for  details  see  Chap.  5): 

Refinement  .S  is  characterized  by  a  set  of  sequential  computations.  The 
semantic  declarations  extend  this  set  as  follows:  take  some  computation  for  S, 
then 

(a)  !C  adds  computations  with  instances  C  — >  C  replaced  by  C, 

and  vice  versa, 

(b)  Cl  &C2  adds  computations  with  instances  Cl  — >  C2  or  C2-^>C1 

swapped, 

(c)  Cl  \\C2  adds  computations  with  instances  Cl  C2  or  C2-J>C1 

replaced  by  Cl  parallel  with  C2. 

Where  further  computations  can  be  obtained,  the  same  declarations  extend 
the  computation  set  thus  derived,  etc.  (transitive  closure). 


Note  that  semantic  relations,  although  valid,  may  not  be  exploitable  (i.e., 
may  not  generate  new  computations)  for  the  refinement  they  are  declared  for.* 


The  declaration  and  exploitation  of 
corns .  We  advise  to  first  declare  all 
only  in  a  later  step  worry  about  their 


semantic  declarations  are  separate  con- 
semantic  relations  that  can  be  proved,  and 
cxploitability. 


'  Example:  A  conventional  for  loop  implementation  with  incremental  step  calculation  will 
render  semantic  relations  between  loop  steps  unexploit.able.  To  exploit  them,  an  index  value 
has  to  be  assigned  to  every  step  before  any  step  is  executed. 
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2.3  Example:  Sorting 


The  problem  is  to  sort  an  array  a[0..n]  of  numbers  into  ascending  order  in 
time  0(n).  Our  refinement  is  an  insertion  sort  adapted  from  [KnuIII]: 


(i>0) 


sort  n 
SO: 


b  i 


cs  x : 


n 

;  Si 

i  =  l 


skip 

cs  i  ;  Si  —  1 

if  a  [i  -  l]>a  [x  ]  then  svjap  i  fi 
swap  i:  t  [x  ]:=a  [x- 1] ;  a[x-l]:  =  a  [x] ;  a[i]:  =  £  [i] 


A  jVi  —  l, +  csx  [i  cs  j 
if 

Note  that  for  |x-j  |>  1 ,  cs  x  and  cs  j  are  disjoint:  they  do  not  share  any  vari¬ 
ables.  Hence  they  fulfil  the  premise  of  the  independence  theorem  and  can  be 
declared  independent. 


To  declare  semantic  relations  for  some  refinement,  one  does  not  need  to 
understand  the  refinement  as  a  whole.  A  local  understanding  of  the  components 
appearing  in  the  declared  relation  is  sufficient.  Most  declarations  come  easily  to 
mind  and  have  a  simple  proof. 


We  will  not  investigate  the  question  of  which  relations  might  be  automati¬ 
cally  declarable,  although  it  is  a  very  interesting  one.  For  the  purpose  of  this 
thesis,  it  suffices  to  assume  that  the  programmer  declares  every  semantic  rela¬ 
tion;  however,  we  permit  the  omission  of  relations  that  hold  always  (see 
Sect.  2.2.2). 
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3  Problem  Specification 

3.1  Semantic  Specification 

The  programming  methodology  presented  here  can  be  applied  to  problems 
that  are  described  by  an  assertion  pair,  what  we  call  a  semantic  specification , 
Let  us  pick  a  problem  and  agree  on  a  name  for  it,  say,  S’.  The  semantic 
specification  of  problem  5  consists  of  an  input  assertion,  S',  pre,  and  an  output 
assertion,  S’,  post: 


S.  pre:  P 
S.  post:  R 

or,  if  it  is  clear  that  S  is  the  problem  referred  to, 

(P.R) 


where  P  and  R  are  predicates.  P  describes  the  problem’s  input  states  and  is 
called  the  input  assertion,  R  describes  the  problem’s  output  states  and  is  called 
the  output  assertion  of  S’.  The  problem  name  S'  can  be  viewed  as  a  statement 
that  has  to  be  refined  such  as  to  transform  P  into  R. 

We  aim  for  results,  and  therefore  do  not  permit  the  false  output  assertion. 
This  restricts  the  range  of  specifiability  to  finite  problems,  those  which  have  ter¬ 
minating  solutions  (the  false  output  assertion  indicates  non-termination).  An 
infinite  problem  must  be  expressed  by  a  specifiable  finite  segment  whose  ter¬ 
minating  solution  can  be  applied  repeatedly. 


3.2  Time  Specification 

The  intention  is  to  make  solutions  to  problem  S’  efficient,  in  general,  noth¬ 
ing  special  has  to  be  specified  to  express  this.  But  for  certain  problems  an  arbi¬ 
trary  attempt  may  not  be  good  enough.  Then  the  semantic  specification  is 
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augmented  by  a  performance  specification.  We  deal  only  with  one  aspect  of 
performance:  execution  time.  Other  important  factors  are,  for  instance,  space 
and  number  of  processors.  (Ideally,  the  sole  criterion  should  be  cost,  which  usu¬ 
ally  involves  all  of  the  above  and  more.) 

Let  us  assume  that  result  S'.  post  is  only  useful  if  obtained  within  a  certain 
time  bound.  Then  a  solution  to  5  can  only  be  considered  correct  if  its  execution 
adheres  to  this  time  bound.  To  request  a  time  bound,  we  add  a  time 
specification  to  the  semantic  specification  of  problem  S': 

•S',  pre:  P 

S'  ,  post:  R  or  ( P.R.t ) 

S.  time:  t 

t  is  an  integer  function  t{2s)  the  problem’s  inputs  £$  (a*^-  is  the  vector  of  vari¬ 
ables  that  appear  in  the  input  assertion  S',  pre)  and  defines,  for  every  input,  a 
time  bound  for  the  execution  of  solutions  to  S.  t  may  also  be  an  "order  of" 
expression. 

In  order  to  verify  a  time  bound,  the  execution  time  of  the  operations  per¬ 
formed  by  the  used  computer  hardware  has  to  be  known.  In  this  thesis  it  will  be 
described  by  a  hardware-dependent  function,  A,  which  maps  every  hardware 
operation,  say,  op  on  an  integer  time  A cp.  For  instance,  A:=  denotes  the  execu¬ 
tion  time  of  an  assignment.  By  predefining  A,  a  time  specification  may  be  linked 
to  a  special  machine,  or  a  class  of  machines.  A  requirement  that  gives  weights  to 
operations  can  be  expressed  this  way.  Such  requirements  are  general  practice 
in  the  analysis  of  the  time  complexity  of  algorithms. 


13.3  Example:  Sorting 

The  problem  of  sorting  an  array  a[0..n]  of  numbers  into  ascending  order  in 
0  (n)  time  can  be  specified  as  follows: 
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n 

sort  7i.  pre:  A  a  [i  ]  €  R 

i-Q 

sort  n.  post:  /\(Q^i<j^n  D  a' [i]^a’  \_j  ] )  A  perm(ct,a,) 

i  j 


sort  n.  time:  0(n) 


where  perm(a,a')  is  the  predicate  that  is  true  if  the  resulting  array  a'  is  a  per¬ 
mutation  of  its  original  value  a,  and  false  otherwise. 
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4  Program  Development  (The  Refinement  Proof  System) 


In  this  chapter  we  introduce  a  preliminary  proof  system  for  the  develop¬ 
ment  of  RL  programs,  the  refinement  -proof  system.  It  is  powerful  enough  to  aid 
the  programmer  in  the  discovery  of  a  solution  to  the  semantic  part  of  the  prob¬ 
lem  specification.  The  refinement  proof  system  describes 

(1)  the  properties  of  a  refinement,  namely  its  semantics  and  (sequential)  exe¬ 
cution  time,  and 

(2)  semantic  properties  of  parts  of  the  refinement,  properties  that  will  suggest 
computations  whose  semantics  are  those  of  the  refinement  but  whose  exe¬ 
cution  times  may  be  different. 

The  refinement  proof  system  deals  with  refinements,  not  with  computa¬ 
tions.  It  can  provide  an  execution  time  for  refinements,  but  not  for  computa¬ 
tions. 

If  the  refinement’s  (sequential)  execution  time  is  not  sufficient,  a  more 
detailed  proof  system,  the  trace  proof  system,  has  to  be  employed.  This  is  the 
realm  of  Chapter  5.  The  trace  proof  system  describes  computations,  so-called 
’'traces",  as  opposed  to  programs,  and  serves  to  verify  that  there  are  traces  that 
have  the  refinement’s  semantics  but  are  sufficiently  fast. 

RL  programs  (described  by  the  refinement  proof  system)  provide  algo¬ 
rithmic  options.  Traces  (described  by  the  trace  proof  system)  reflect  algo¬ 
rithmic  decisions. 

From  now  on  we  will  use  the  following  terminology: 

Definition: 

(a)  A  sia.te-rn.enL  is  a  skip,  assignment,  or  refinement  call. 
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(b)  A  refinement  List  is 

(i)  a  statement,  or 

(ii)  a  composition  &  1 m,  s  2  of  two  statements  S 1  and  S2,  or 

(iii)  an  alternation  if  B1  -*  SI  [}...  [J  Bn-*  Sn  fi  using  n  logical  expressions  Bi 
and  n  statements  Si.  Bi ->  Si  is  a  guarded  command  with  guard  Bi 
and  alternative  Si. 

(c)  A  refinement  is  the  association  of  a  refinement  list  SL  with  an  identifier  *5* 
by  .S’:  SL.  We  also  call  SL  the  refinement  of  S,  and  S  the  refinement  name 
for  SL. 

(d)  The  application  of  statement  S'  in  a  refinement  is  an  instance  of  S,  or  also,  if 
S'  is  a  refinement  name,  a  call  of  S. 

(e)  The  statements  and  guards  in  the  refinement  of  S'  arc  the  primary 
components  ( primary  statements  and  primary  guards )  of  S.  The  applica¬ 
tion  of  a  primary  component  by  S  is  a  primary  component  instance  of  S'. 

(f)  The  proper  components  of  a  refinement  S'  are  its  primary  components  and 
their  proper  components  (transitive  closure). 

(g)  The  components  of  S  are  S  itself  and  its  proper  components  (reflexive  tran¬ 
sitive  closure). 

(h)  Statements  for  which  no  refinement  is  given  and  guards  are  basic.  State¬ 
ments  that  are  refinement  calls  are  refined. 

(j)  Variables  and  constants  that  appear  exclusively  in  components  of  S  are 
local  to  S.  Variables  and  constants  that  appear  in  S  and  in  some  S'  which  is 
not  a  component  of  are  global  to  S'  and  shared  by  S'  and  S'.  Variables  glo¬ 
bal  to  S  that  are  changed  only  by  components  of  S  are  private  to  S’. 

(k)  We  will  denote  a  specific  instance  of  component  C  in  some  refinement  list  by 
the  lower  case  equivalent,  c,  and  consider  this  name  unique  to  that  instance 
of  C.  Component  instances  can  be  interpreted  as  different  components, 
each  with  only  a  single  application  (to  syntactically  transform  different 
instances  of  component  C  into  different  components,  apply  the  following 
replacement  algorithm:  replace  every  instance  of  C  by  a  unique  name  c  and 
add  c:  C  before  that  instance  of  C;  if  c  is  recursive,  identify  its  recursive 
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calls  by  cf  c%.  l  ). 

(l)  Refinement  S'  with  a  set  D  of  semantic  declarations  is  the  semantic  version 
of  5  described  by  D,  denoted  SD.  (If  D=<f>,  SD  is  S.) 

(m)  A  semantic  version  SD  that  may  be  called  from  a  user  environment  is  an  RL 
program. 


4.1  Timed  Assertions 

Our  methodology  will  enable  not  only  the  determination  of  total  semantic 
correctness  but  also  the  derivation  of  an  upper  bound  for  the  program’s  execu¬ 
tion  time  that  might  be  a  prerequisite  for  performance  correctness.  Therefore 
we  must  use  timed  assertions  for  the  description  of  program  states.  The  idea  is 
similar  to  [Shaw79]. 

Definition: 

A  timed  assertion  P  is  of  the  form  PSemAPtjme.  where  the  semantic 
part,  Psem,  is  a  predicate  about  the  program’s  variables,  and  the  time  part, 
or  time  stamp,  Ptime.  is  a  predicate  asserting  the  state  of  a  fictitious  vari¬ 
able,  clock,  as  an  integer  function  timep  of  the  vector  a?  of  program  vari¬ 
ables: 

Ptime  -df  dock  ^timcp(^) 

A  timed  assertion  with  time  part  true  is  a  semantic  assertion.  A 
timed  assertion  with  semantic  part  true  is  a  time  assertion  or  time  stamp. 

Variable  clock  simulates  a  clock  that  keeps  track  of  the  execution  time  of 
the  program.  It  is  a  hidden  variable  [Len78],  appearing  in  assertions  but  not  in 
programs.  It  is  not  an  auxiliary  variable  [0wCr76a,  0wGr76bJ.  Both  hidden  and 
auxiliary  variables  need  not  be  implemented,  but  auxiliary  variables  must  be 
added  to  the  program  t.o  obtain  a  semantic  proof.  This  methodology  does  not 
require  auxiliary  variables. 
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The  time  stamp  of  timed  assertion  P  specifies  an  execution  time  constraint 
for  the  program  state  described  by  the  semantic  part  of  P.  In  accordance  with 
the  weakest  precondition  calculus  in  which  programs  are  derived  from  the 
postcondition  "backwards",  we  run  the  program  clock  backwards,  i.e.,  view  time 
as  "running  out"  rather  than  progressing.  A  time  stamp  may  be  interpreted  as  a 
predicate,  Pti me,  or  a  function  timep,  whatever  is  more  convenient.  To  make  the 
parts  of  timed  assertion  P  explicit,  we  will  occasionally  write  (Psem,  Ptime)  or 
(Psem.  timep). 

Definition: 

Consider  statement  S'  and  assertions  P  and  P.  We  let  [P]  S  [R]  stand 
for  an  argument  that  establishes  the  truth  of  the  formula  Pi)  S\R],  i.e.,  a 
proof  that  component  S  terminates  and  transforms  assertion  P  into  asser¬ 
tion  R.  We  call  \P]  S  [R]  a  proof  of  total  correctness  of  S  with  respect  to 
specification  (Psein,  Pscm,  timep-timep) .  The  derivation  of  \P\ S  \R] 
yields  for  every  statement  S'  of  S  an  assertion  P'  satisfying  the  formula 
P' D  S' \R'  where  R'  is  an  assertion  previously  derived  and  known.  P'  is 
called  the  precondition,  pre(S'),  R'  the  postcondition,  post(*S"  ),  of  S'  in  the 
proof  \P  ]  S  [R  ] . 

A  proof  of  S'  can  be  outlined  by  framing  every  statement  in  the  pro¬ 
gram  text  with  its  pre-  and  postcondition  enclosed  in  curly  brackets. 
[0wGr76a]  calls  this  a  proof  outline  and  gives  an  example. 

When  proving  a  solution  to  some  timed  problem  specified  by,  say,  (P,R, t) 
(where  P  and  R  are  now  semantic  assertions),  we  normalize  the  output  time 
stamp  to  0  to  obtain  as  input  time  stamp  t,  and  write  \P,t\  S  [R\  for 
\P,t  ]  S  \R ,  Oj .  [P,t  ]  S  \R]  can  be  read:  "in  order  for  S  to  establish  R,  nothing 
more  than  P  has  to  hold  immediately  before  the  execution  of  S]  also,  if  we  start 
P  with  a  supply  of  at  least  t  time  units  (docket),  the  execution  of  S  will  not 
exceed  that  supply  of  time  (clocks. 0)."  Consequently,  the  execution  of  S'  will  not 
require  more  than  t  time  units  (choose  t  as  input  time). 

There  are,  in  general,  many  different  proofs  of  S  with  respect  to  ( PsR,t ).  As 
a  solution  to  a  logical  inequality,  P'  is  one  of  manjr  admissible  preconditions  for 
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statement  5’  of  S'.  It  is  best  to  select  the  closest  possible  approximation  of 
weakest  precondition  S"  \R'  j  for  the  proof.  Everything  stronger  than  the  weakest 
precondition  adds  unnecessary  constraints,  but  the  weakest  precondition  itself 
may  be  difficult  to  express  [Dij7t>]. 


4.2  Formal  Refinement 


This  section  presents  the  formal  definition  of  the  programming  language  RL 
and  its  refinement  mechanism.  The  language  features  of  RL  are  described  by  a 
set  of  axiomatic  weakest  preconditions,  so-called  "language  rules".  Each 
language  rule  defines  the  semantics  and  execution  time  of  one  programming 
feature.  The  process  of  program  refinement  is  governed  by  four  "refinement 
rules".  Each  refinement  rule  states  for  a  different  refinement  option  under  what 
conditions  it  is  applicable. 

Most  of  this  section  is  condensed  from  previous  publications,  notably  of 
Dijkstra  [Dij76j  and  Hehner  [Heh79j. 


4.2.1  Language  Rules 

This  section  presents  the  formal  definition  of  the  programming  language  RL. 

In  the  following  rules  we  denote  the  evaluation  time  of  expression  E  by  a 
function  T (E).  This  thesis  is  not  concerned  with  the  optimization  of  expression 
evaluations  (see,  e.g.,  [Kuck77,  St.o67]  for  research  in  this  area),  and  therefore 
we  do  not  provide  a  rigorous  definition  for  T (E ).  However,  we  will  later  in  this 
section  define  T(.S’),  the  execution  time  of  a  statement  5. 

The  rules  also  refer  to  an  implementation-dependent  function  A  that  maps 
each  hardware  operation  on  its  execution  time.  A  discussion  of  A  is  beyond  the 
scope  of  this  thesis.  Note  that  for  concurrent  parts  of  a  computation  that  are 
executed  on  processors  of  different  types  different  functions  A  apply. 
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Definition  (Language  Rules): 

For  all  timed  assertions  R  and  some  implementation-dependent 
integer-valued  function  A: 

(LI)  null:  skip*/?}  =df  R 

(L2)  assignment: 


x:-E\R]  =df 

x,  clock 

(a) 

simple: 

RE,  clock -T(E)-&:= 

(b) 

subscripted: 

x[E1  ]  :-E2[R] 

— df 

X, 

clock 

R{x\E1  :E2  ),  clock -T(E1  )-T(E2)- A:= 

Thus  an  array  is  treated  as  a  (partial)  function  and  an  assign¬ 
ment  to  an  array  element  as  a  change  in  the  whole  function  (as  in 
the  axiomatic  definition  of  Pascal  [HoWi73]). 

For  the  sake  of  simplicity,  we  do  not  distinguish  the  execution  time 
of  a  simple  and  a  subscripted  memory  reference:  A.=  is  identical  in  both 
cases.  We  are  also  assuming  that  the  value  of  an  expression  is  always 
within  the  domain  of  the  variable  it  is  assigned  to. 

(L3)  composition:  S1;S2{R\  =df  SI  \S2{R]\ 

Note  that  the  time  part  of  this  rule  reflects  the  time  of  sequential 
execution:  the  input  time  stamp  of  S2  serves  as  output  time  stamp  of 
SI.  However,  this  is  only  a  first  estimate.  Semantic  declarations 
(Sect.  4.3)  may  yield  computations  for  SI  ;S2  with  improved  execution 
time. 


(L4) 


n 

We  can  parameterize  composition:  ;  Si  stands  for  SI  Sn  .  We 

i=i 

call  this  construct  a  for  loop.  The  loop  bounds  must  be  constant  in  the 
loop  scope,  i  is  a  constant  for  every  step  Si  and  local  to  the  loop. 


alternation: 


if  B1-+S1  8  ...  [|  Sn  fi \R  } 

,  n  ,  Clock 

(  V  /\  Si  j )  )  clQck _r^gi . ) _ A.f 


T (B1,...,Bn)  denotes  the  evaluation  time  of  guards  We 

could  set  T (B1  ,...,Bn)  —^^{Bl  )+...  + T (Bn),  but  often  not  all  guards  will 
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have  to  be  evaluated.  A  detailed  definition  of  T (B 1  ,...,Bn)  is  not  of  our 
concern.  Ajf  accounts  for  the  branches  necessary  to  select  an  alternative. 

If  no  guard  is  true  the  alternation  fails.  The  present  rule  assumes 
that  no  two  guards  will  be  true  at  the  same  time,  i.e.,  that  the  alterna¬ 
tion  is  deterrrrvLTiisHc.  We  make  this  restriction  in  order  to  keep  opera¬ 
tional  models  for  programs  simple.  Non-determinism  requires  a  back¬ 
tracking  mechanism  in  trace  models  for  programs  [Hoa78a]. 

(L5)  refinement  call:  (call  Sd  with  actual  indices  c  of 

refinement  Sy:  SL  with  formal  indices  y) 

ij.  clock 

(a)  no  recursion:  S6\R]  SL{R]^  ,  . 

c,  clock  -T(c  )~ ACftJ] 

Aca)i  represents  the  time  spent  transferring  control  to  the 
refinement  body. 

(b)  direct  recursion: 

A  recursive  refinement  is  approximated  by  a  sequence  of 
increasingly  deeper  finite  recursions.  To  express  the  approximations 
we  need  a  fail  statement  that  will,  however,  not  appear  in  RL  pro¬ 
grams,  its  sole  purpose  is  to  define  formally  recursive  refinement: 

fail:  abortf/?  ]  false 

The  zth  approximation  (Si/)i  of  recursive  refinement  Si}:  SL 
performs  at  most  i  recursive  steps  or  fails: 

(Si}) 0:  abort, 

(i>0)  ( Stf),:  . 

Note  that  is  a  component  of  (S'^)i.  The  properties  of  recur¬ 

sive  call  Sd  are  the  limit  of  the  properties  of  its  finite  approxima¬ 
tions  (.S'c)i : 
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S<*\R]  s*  \Z(SS)i[R] 

iSO 

(c)  indirect  or  multiple  recursion: 

The  definition  of  the  approximations  is  messier  but  conceptu¬ 
ally  not  different:  they  also  represent  increasing  levels  of  recursion 
(see  [Heh83]). 

To  avoid  proving  a  refinement  S  for  different  postconditions  R,  calls 
can  be  related  to  a  single  refinement  proof  with  respect  to,  say,  postcon¬ 
dition  Q  (Q  should  not  refer  to  indices  or  local  variables  of  S):  if  2  is  the 
list  of  global  variables  of  S  and  ranges  over  the  values  of  2?  which  estab¬ 
lish  Q, 

(StlQ]  A  3  S6[R] 

The  details  of  this  and  a  still  simpler  call  rule  are  discussed  in  [GrLe80]. 
A  more  general  reference  is  [Gri8l]. 

Examples: 

(1)  x:-x  +  \[x-c  ,  clocks]  =  ( x  =c-l ,  clock  ^  T(:r  +  1)+A;=  ) 

(2)  x\-x  +  l\  x:=x  +  l  fx  =  c  ,  clocks  0]  =  x:=x  +  l[x=c  —  1 ,  clock  ^  T(ar  +  l)+A;=j 

=  (  x  =  c-2,  clock  ^  2T(x  +  l)+2A:=  ) 

(3)  if  ->  x:  =  0  []  x  =  0  ->  skip  fifx^O,  cfocfc^Oj 

clock 

3  clock  ST(0)  +  A;=)V(x  =  0,  clock* 0))ctocfc_T(x^a  x=0)_Aj( 

=  '*’  (x^O,  clock  ^ T(0)+A:=+T(x )+Atest+Aif ) 

V  (  a:  =0 ,  clock  >  T(a;  )+Atest+Ail ) 

Some  remarks  on  for  loops  are  necessary: 

A  for  loop  is  an  indexed  composition,  but  the  corresponding  semantic  rule 

(L3)  does  not  describe  the  properties  of  the  index  calculation.  Consequently, 

although  index  calculations  may  be  part  of  a  program,  they  will  not  be  described 

by  that  program’s  formal  properties.  The  following  assumptions  justify  the 

!  Here  we  describe  the  g\iard  evaluation  time  T(x^0,  z=0)  as  the  time  T(r)  needed  to 
fetch  x  plus  the  time  Alest  of  testing  x  for  0. 
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neglect  of  index  calculations: 

(a)  For  any  for  loop,  all  index  values  can  be  calculated  before  any  step  is  exe¬ 
cuted. 

This  assumption  permits  the  neglect  of  index  calculations  for  semantic 
dcclnrati  ons. 

(b)  Index  calculations  are  typically  a  negligible  part  of  the  program. 

This  assumption  justifies  the  neglect  of  the  execution  time  of  index  cal¬ 
culations.  (If  all  index  values  are  calculated  concurrently  with  program 
parts  previous  to  the  for  loop,  their  impact  on  the  program’s  execution 
time  is  indeed  close  to  nil.) 

The  semantic  part  of  (Ll)  to  (L3)  is  taken  from  Dijkstra  [Dij76],  except  for 
the  subscripted  assignment  rule  (L2b)  which  is  from  [Gri78].  The  semantic  part 
of  (L4)  is  a  weakened  version  of  Dijkstra’s  alternation  rule  [Dij75,  Dij76]:  we 
presume  deterministic  alternations.  The  semantic  part  of  (L5)  is  from  [Heh?9] 
and  subsumes  Dijkstra’s  do...od  repetition  rule  [ D i j 7 6 ] .  The  time  part  of  (Ll)  to 
(L5)  is  new,  but  a  similar  execution  time  calculus  for  a  similar  language  can  be 
found  in  [Shaw79]. 

To  test  that  RL  as  defined  by  the  language  rules  has  some  elementary, 
always  desirable  properties,  we  can  check  that  the  language  rules  satisfy  a  set  of 
suggested  healthiness  criteria: 

Definition  (Healthiness  Rules): 


(HI) 

.S^false}  =  false 

(excluded  miracle) 

(H2) 

R1  D  R2  D  S[R1]DS\R2] 

(monotonicity) 

(H3) 

S\R1  ]AS\R2]  =  S[R1AR2] 

(H4) 

S{R1]\/S{R2 J  =  S\R1\/R2\ 

(H5) 

A  (Rk?Rk  +  x)  d  S\\/Rk]=  V  S[R/cl 

k  £Q  k  >0  k 

(continuity  in  postconditions) 

(HO) 

s*  s 

A  =  SLs}R]0SLs 

i  °i  ^i+l 

\R  j  )  (continuity  in  statements) 

(Hi)  to  (H5)  have  been  proposed  by  Dijkstra  [Dij76];  (K6)  appeared  later. 
This  list  is  not  exhaustive;  more  healthiness  rules  could  be  added.  For  a  proof  of 


-  28  - 


(HI)  to  (H6)  for  the  semantic  part  of  language  rules  (LI)  to  (L5)  see  [Heh83].  The 
time  part  does  not  pose  any  healthiness  problems:  it  can  in  every  language  rule 
be  interpreted  as  an  assignment  to  the  hidden  variable  clock,  and  assignments 
are  healthy. 

Further  properties  follow:  for  instance,  we  can  prove  Hoare’s  "rule  of  conse¬ 
quence"  [Hoa69]: 

\P'\  S  \R’\,  PdP'  ,  R’dR 
IP]  S  [R] 

Proof: 

We  may  assume  \P'  $  S  (/?'],  PdP',  R’dR 
and  have  to  deduce  \P  ^  S  [R]  . 

(R'dR)  d  ( S[R']dS\R j)  is  guaranteed  by  (H2). 

Therefore,  using  our  definition  of  \P'  }  51  \R'  j  , 

\P']S[R'\  =  ( P'dS\R'\ )  D  (P  D  S\R\)  ,  and  thus 

(PdP')  d  (Pd  S  \R\)  =  \P\ S  \R\ 

The  execution  time  of  a  statement  S’  is  defined  as  its  weakest  time  precon¬ 
dition  with  respect  to  time  postcondition  0: 


Definition: 

The  execution  time  T (S)  of  statement  S’  is  T(5)  S  [clock^0]Ume 

(Remember  that  )  can  be  interpreted  as  a  predicate  or  a  function.) 

To  conclude  this  section,  let  us  investigate  the  execution  time  of  some 
example  refinements: 

Consider  the  following  program  computing  the  factorial  of  n: 

fact  n :  if  n  =  0  ->  r  :  =  1 

[J  n>0  -»  fact  n—  1 ;  r:=r  n 


fi 
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We  can  determine  the  number  of  multiplications  performed  by  call  fact  k 
by  assuming  a  machine  A  that  only  takes  time  for  multiplications  (one  time  unit 
per  multiplication): 

T(fact  0)  =  0 

(fc>0)  T (factfc)  =  T(fact,  k  —  1)  4-  1 

which  yields  T(factk)  =  k  with  domain  fc^O.  For  the  derivation  of  the  formal 
properties  of  fact  k  see  App.  A.  1. 

To  illustrate  further  that  our  axiomatic  system  can  be  used  to  determine 
the  time  complexity  of  algorithms,  here  is  a  second  example,  a  program  which 
searches  for  a  number  x  in  an  ordered  array  —  l]  (binary  search): 

BS:  if  i=j  -»  found:-f alse 

Q  i<j  -*  k  :  =  div(i  +j,  2) ; 

if  a[fc]<x  -*  i:=fc  +  l;  BS 
(1  a\k]=x  found  :  =  true 

A  a\jc  ]>ar  ->  j:=k  —  1 ;  BS 

n 

g 

We  want  to  count  the  tests  of  elements  in  array  a\i..j  —  l].  We  therefore  set 
T(a [k  ]<x,  a  [fc]=x,  a[fc]>x)  =  l,  and  let  every  other  operation  be  for  free.  We 
are  only  interested  in  the  worst  case  over  all  possible  array  inputs  of  a  fixed 
length,  i.e.,  an  upper  bound  f(j~i)  in  the  array  length  j—i  :  T (BS)  ^  f  (j—i)  . 
One  worst  case  occurs  when  each  comparison  of  a[/c]  and  x  establishes  a[fc]<x  . 
Inspection  of  BS  yields  for  / (j -i)  the  recursive  equation 

/0‘ “1 0.  =  1  +  /0‘ -div(i+y,  2)+l)  =  1  +  f(\j  -  ~^-\)  =  1  +  /( L^i^J) 

Following  standard  complexity  methods,  we  substitute  2'°g2^  for  j  — i  to  obtain 
T (BS)  1  f(j-i)  =  0  (fiog20  —i)l)  . 
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4.2.2  Refinement  Rules 

While  the  language  rules  describe  the  properties  of  the  programming 
features  of  RL,  the  following  refinement  rules  ensure  the  derivation  of  a  semanti¬ 
cally  totally  correct  program,  i.e.,  a  program  that  satisfies  the  semantic  prob¬ 
lem  specification  and  provide  a  proof  that  complies  with  the  language  rules. 

Definition  (Refinement  Rules): 

Consider  semantic  specification  ( P,R  ) .  To  obtain  a  refinement  such 
that  [P]  S  [R]  choose  one  of  the  following: 


(Rl) 

continuance: 

choose 

5 :  skip 

if  PdR 

(R2) 

replacement: 

choose 

51 :  x\-E 

if  PdR 

(R3) 

divide -in-2: 

choose 

S:  SI ]S2 

if  \/(PDS1  \Q]  A  Q^S2[R  }) 

Q 

A  divide-in-n  comprises  n-1  divide-in-2  refinements  in  one  step.  A 
special  case  of  divide-in-n  is  the  for  loop  (see  previous  section). 

(R4)  case  analysis:  choose  S:  if  B1->  SI  [j  ...  |  Bn  -*  Sn  fi 

if  P  D  V  (Bi  ASi\R]) 

4.—  1 

Rules  (R3)  and  (R4)  ask  for  further  refinements.  For  more  details  on  their 
proper  choice  see  the  notion  of  progress  in  [Heh79], 

The  refinement  rules  are  taken  from  [Heh79],  except  that  our  case  analysis 

reouires  deterministic  alternations. 

-1. 


4.3  Formal  Treatment  of  Concurrency 

The  refinement  rules  guarantee  only  semantic  (not  time)  correctness.  A 
specified  execution  time  constraint  may  not  be  met  because  only  semantic 
assertions,  not  time  stamps,  are  taken  into  account.  If  the  refinement  is  too 
slow,  declarations  of  semantic  relations  between  certain  refinement  components 
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have  to  yield  a  faster  version. 

This  section  deals  with  the  mechanism  by  which  the  execution  time  of 
refinements  can  be  improved:  semantic  relations  and  their  declaration.  Seman¬ 
tic  declarations  do  not  extend  or  change  the  refinement  in  any  way.  They  only 
make  some  of  its  properties  more  apparent,  properties  that  can  be  exploited  to 
speed  up  the  execution. 


4.3.1  Semantic  Relations 

Semantic  relations  provide  information  about  the  semantic  properties  of  a 
refinement.  This  information  can  be  used  to  improve  the  refinement’s  perfor¬ 
mance.  We  consider  five  semantic  relations:  idempotence,  commutativity,  full 
commutativity,  non-interference,  and  independence. 

To  determine  the  full  commutativity  of  two  refinements  we  will,  at  least  in 
the  general  case,  have  to  identify  the  postconditions  for  their  primary  com¬ 
ponent  instances.  Therefore  we  introduce  the  notion  of  a  tail: 

Definition: 

Consider  refinement  S :  SL  and  a  primary  component  instance  c  of  S. 

The  tail  t(S,c  )  of  S'  with  respect  to  c  is  the  part  of  SL  that  succeeds  c: 

(i)  if  S:  s'  then  t(S.s'):  skip. 

(ii)  if  S:  s1:s2  then  t(S.sl):  s2  ,  and  t(S,s2 ):  skip, 

(iii)  if  S:  if  ...  |J  bi  -*•  si  fl  ...  fi  then  t(S,bi):  si  ,  and  t(S,si ):  skip. 

In  the  following,  components  in  general  are  denoted  with  the  letter  C,  state¬ 

ments  in  particular  with  S,  and  guards  with  B. 

As  the  refinement  rules  (see  previous  section),  the  semantic  rules  are 
defined  with  respect  to  semantic  postconditions  only: 
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Defmition  (Semantic  Rules): 

A  semantic  relation  is  an  expression  of  the  form  !  C ,  Cl  Sc  C2  , 
C1XC2  ,  Cl  C2  ,  or  Cl  ||  C2  . 

For  any  semantic  assertion  R, 

(51)  idempotence: 

■  r  B  =df  true 

!rS  (S\R]=S;S\R\) 

(52)  commutativity: 

B1  ScrB2  true 

S&rB  =dr  {BAS\R]  =  S\BAR\) 

S1&rS2  =d,  (  SI  \SZ\R]  =  S2\S1  \R\) 

(53)  full  commutativity: 

(a)  basic  Cl  and  C2:  Cl  &rC2  Cl  &RC2 

(b)  basic  C,  and  refined  S  with  primary  component  instances  c*: 

S*rC  A 

1  * 

(c)  refined  S,  and  refined  S'  with  primary  component  instances  c*’: 

SXRS'  A5^J(S»iC,.)j/)|C1’ 

(54)  non-interference: 

Cl  C2  ={if  any  expression  E  in  Cl  contains  at  most  one  refer¬ 
ence  to  at  most  one  variable  changed  in  C2\  if  Cl 
r  contains  x:—E  and  C2  references  x,  then  E  does 

not  refer  to  x  nor  to  any  variable  changed  by  C2\ 
also,  all  of  the  above  holds  with  Cl  and  C2  inter¬ 
changed. 

(55)  independence: 

Cl  lb  C2  =df  Cl  *R  C2  A  Cl  4*  C2 
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Examples: 

) 

(1)  S:  x  := 3 ,  fRS  =  (x:=3[R]  =  x:=3\x:=3[R])  =  (R,^  =  (-^3)3 )  —  ^rue 

(2)  51:  x:=y  ,  B:  x=3,  S  <ScR  B  ==  (x  =  3A  x\—y  \R]  =  x  :-y  \x=3/\  R\)  = 

(x  =  3A Ry  =  y  =  3/\Ry  )  =  (R*  D  (x=3  =  y-3) ) 

(3)  S1:y:=x  + 1,  S2:x i-^3, 

S1Scy-cS2  =  ( y  :  =  x+  1;  x:  =  3{y  =  c  ]  =  x  :  =  3;  y  \-x  +  l\y  =c  ] )  = 

(  ((y  ~c  )n)x  4. 1  =  iiy  ~  +  ==  =  c  —  3+  1  —  c  )  s:-  (  a:  =3  ) 

Every  semantic  relation  ZR  consists  of  equivalences  SL1  { R  j  =  SL2\R  $  .  In 
case  an  equivalence  is  difficult  to  prove,  try  to  prove  something  stronger:  the 
conjunction. 

Let  us  discuss  non-interference  (S4).  This  relation  is  taken  from  Gries 
[Gri77j,  but  Gries  does  not  give  it  a  name  and  calls  something  else,  close  to  our 
full  commutativity,  non-interference.  We  quote  some  examples  from  [Gri77]: 

Suppose  component  Cl  changes  a  variable  a.  In  order  for  component  C2  not 
to  interfere  with  Cl ,  it  may  not  contain  statements  like  a:  =  a  +  l  or  6:  =  a  +  a  +  l. 

If  Cl  references  a,  then  in  C2  an  assignment  a:  =  a+l  must  be  written 

£:  =  a  +  l;  a:  =  t  ,  where  t  is  not  shared  by  Cl.  The  same  restriction  holds  for  an 
array,  where  we  consider  an  assignment  a[i]:—E  to  be  a  change  of  the  whole 
array  a.  Although  the  non-interference  relation  (S4)  looks  syntactic,  it  is  a 
semantic  condition:  if  there  are  subscripts,  the  set  of  common  variables  may 
depend  on  the  subscripts’  values. 

(S4)  requires  indivisibility  of  memory  reference.  To  quote  [Gri77]  again: 

Suppose  component  Cl  changes  variable  (location)  A*  while  component  C2 
is  referencing  A.  The  memory  must  have  the  property  that  the  value  of  A  which 
C2  receives  is  the  value  of  A  either  before  or  after  the  update,  but  not  a  possible 
intermediate  value. 

^  It  is  presumed  that  each  assignment  updates  only  one  memory  location. 
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There  is  no  reason  why  we  should  insist  on  this  specific  non-interference 
criterion  (S4)  other  than  that  we  believe  it  is  the  most  practical.  Other  non¬ 
interference  relations  that  make  different  demands  at  the  hardware,  e.g., 
existence  of  a  test-and-set  operation  may  replace  (S4).  Be  aware,  however,  that 
the  choice  of  non-interference  criterion  determines  the  independence  a 
refinement  will  contain. 

The  following  relation  of  free  non-interference  does  not  rely  on  nice 
hardware  properties.  It  is  stronger  than  (S4)  and  thus  yields  less  independence: 

free  non-interference: 

free 

Cl  -4*  CZ  =df  neither  Cl  nor  C2  reads  a  bit  that  the  other 

changes;  Cl  and  CZ  may  change  a  common  bit  b  if 
all  assignments  to  6  by  Cl  or  CZ  yield  the  same 
value,  and  neither  Cl  nor  CZ  reads  b. 

free  independence: 

free 

Cl  ||  rCZ  =*  Cl  aR  CZ  A  CI^CZ 

free 

Certainly  ClA^CZ  does  not  imply  C7+f>  CZ  ,  but  curiously,  although  it 

free 

should,  Cl  <-f*  CZ  does  not  imply  Cl  CZ  either.  Consider  the  following  situa¬ 
tion  (due  to  Eike  Best): 

Let  x  and  y  be  two-bit  variables,  x,y  e(0,  1,  2,  3} .  Then  the  refinements 

SI  :  x  :=  2  (y  mod 2)  +  x  mod 2 
SZ :  x  :=  2-  (x  mod2)  +  y  mod2 

free 

do  interfere,  ~(S7  <f>  SZ ) ,  but  do  not  interfere  freely,  SI  ^  SZ  :  SI  swaps  the 
high-order  bit  of  x  with  the  low-order  bit  of  y,  and  SZ  swaps  the  other  two  bits. 
The  reason  is  that  the  definition  of  that  we  adopted  from  [Gri77]  is,  simply 
but  restrictively,  phrased  in  terms  of  variables,  not  in  terms  of  bits.  Naturally, 
free  non-interference  works  also  on  machines  with  indivisible  memory  refer¬ 


(S4’) 


(35') 


ence. 
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Proofs  of  semantic  relations  follow  the  same  concept  as  proofs  for  state¬ 
ments,  but  the  terminology  differs  somewhat: 

Definition: 

(1)  Consider  semantic  relation  Z  and  semantic  assertions  P  and  R.  We  let 
[P]  Zr  stand  for  an  argument  that  establishes  the  truth  of  the  formula 
PdZr  .  We  call  \P  \  Zr  a  proof  of  semantic  relation  Z  for  scope  (P.R)  •  P  is 
called  an  enabling  condition ,  R  a  result  condition  for  Z. 

(2)  A  proof  of  semantic  relation  Z 


for  scope 

is  denoted 

and  Z  is  called 

(0 

(P,R  )  for  every  R 

\P\z 

general  under  P 

(ii) 

(true,/? ) 

Zr 

unconditional  for  R 

(iii) 

(true,/?)  for  every  R 

Z 

global 

For  proofs  of  full  commutativity,  Cl  X  02  ,  globality  is  a  very  important  con¬ 
cept.  If  all  mutual  commutativities  that  constitute  relation  01x02  hold  glo¬ 
bally.  the  consideration  of  intermediate  proof  assertions  in  01  and  02  can  be 
spared.  A  full  commutativity  whose  mutual  commutativities  are  not  global 
reflects  very  difficult  semantics  for  which  no  easy  handles  should  be  expected. 
In  fact,  most  semantic  declarations  should  be  global  -  at  least  within  the  realm 
of  the  refinement  they  are  declared  for  (this  weaker  form  of  globality  is  called 
"program-specific";  see  Sect.  5.3). 

As  a  guideline  for  a  derivation  of  refinements  with  potentially  high  con¬ 
currency  there  is  a  theorem  that  guarantees  the  free  independence  of  two 
refinement  components.  Most  independence  declarations  will  be  applications  of 
this  theorem  and  will  not  require  an  extra  proof: 

Theorem  (Independence  Theorem): 

Two  components  01  and  02  of  which  neither  changes  any  variables 
appearing  in  both  can  be  declared  globally  freely  independent. 
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Proof: 

B1  Sc  B  2  : 

Always  true. 

SScB  : 

Pick  any  postcondition  R.  According  to  the  premise  B  does  not  refer 
to  program  variables  changed  by  5".  Therefore  S'  keeps  B  invariant: 

S\B\  =  B 

Commutativity  follows  by  the  identities: 

BAS\R]  =  S\B]AS{R]  =  S[BAR] 

SI  &S2  : 

Pick  any  postcondition  R.  For  any  statement  S,  the  weakest  precondi¬ 
tion  S[R]  is  derived  by  substituting  variables  changed  by  S'  in  R,  maybe 
using  case  analysis.  According  to  the  premise,  the  vector  £  of  variables 
changed  in  one  or  both  of  57  and  S2  is  split  into  two  distinct  subvectors  x*1 
of  the  variables  changed  by  SI ,  and  xk  of  the  variables  changed  by  S2. 
SI  \R]  results  from  substituting  only  variables  of  xl  by  expressions  using 
only  variables  of  xl  and  constants,  and  analogously  for  S2.  (For  the  pur¬ 
pose  of  this  proof,  program  variables  changed  neither  by  SI  not  by  S2  can 
be  considered  constants.)  Such  distinct  substitutions  yield  the  same 
result,  in  whatever  order  performed.  Therefore 

S1\S2\R]\  =  S2  [SI  \R  ]] 

Cl  ZC2  : 

The  previous  argument  can  be  applied  to  any  pair  of  components  of 
Cl  and  C2. 

free 

Cl  C2  : 

Clear:  there  are  no  common  data. 

We  can  relax  the  independence  theorem  in  one  special  case  to  make  full  use 
of  the  requirement  for  free  non-interference: 
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Theorem  (Supplement  to  Independence  Theorem): 

Globally  freely  independent  components  Cl  and  C2  may  assign  the 
same  value  to  a  global  bit  variable  as  long  as  neither  of  them  reads  that 
variable. 

We  conclude  this  section  with  the  proof  of  a  property  mentioned  in 
Sect.  2.2.2,  which  permits  the  neglect  of  the  hidden  guarded  command 
~B  -*  skip  in  if  B  then  S'  fi: 

Lemma: 

For  all  statements  S,  guards  B,  and  timed  assertions  R , 

S  ScR  B  D  S  &r  ~B 

Proof: 

(a)  Assume  S&RB  and  RdB  . 

Then  BAS{R]  =  S\BAR\  =  S\R]  yields  S\R]dB  . 

Thus  ~BAS[R]  h=  false  =  S\~BAR],  i.e.,  S&R~B. 

(b)  Assume  SScRB  and  R  D  . 

Then  BAS\R\  =  S[BAR]  =  Sf  false}  =  false  yields  S' [/? }  D  . 

Thus  ~BAS\R\  =  S{R\  =  S  [~BAR }  .  i.e.,  S&R~B. 

The  lemma  expresses  that  statement  S'  keeps  guard  B  invariant  if  S’  com¬ 
mutes  with  B.  S  &R  B  says  that,  while  establishing  R,  S  preserves  the  truth  of  B\ 
S  &R  rv  B  says  that,  while  establishing  R,  S  preserves  the  untruth  of  B. 

4.3.2  Semantic  Declarations 

Semantic  relations  are  documented  in  the  program  text  by  way  of  semantic 
declarations. 

Definition: 

A  semantic  declaration  is  a  semantic  relation  Z  stated  after  or  within 
some  refinement  S  for  some  scope,  i.e.,  with  optional  enabling  condition  P 
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and  result  condition  R.  For  in-line  declarations  in  refinement  S,  P  and  R 
are  intermediate  proof  assertions  for  S. 

The  syntax  of  semantic  declarations  is  described  in  Sect.  2.2.2.  We  will  only 
declare  iderripoLenee,  commutativity,  and  independence. 


4.4  Example:  Sorting 


We  will  now  prove  the  sorting  program  of  Sect.  2.3  with  respect  to  the 
semantic  part  of  the  specification  in  Sect.  3.3.  We  will  also  derive  the  worst-case 
execution  time  of  the  refinement  and  find  out  that  it  does  not  satisfy  the  time 
specification.  We  do  not  yet  have  the  tools  for  a  time  proof  of  sort  n  with 
independence  declaration. 

Let  us  denote  the  execution  time  of  a  comparison  by  c  and  that  of  a  swap  by 
s,  and  let 


a 


Then  the  properties  of  the  refinement’s  components  are: 


n 


sort  n:  \  S  i 

i=i 


5  0:  \R  \  skip  [R  $ 

(x>0)  Si:  \cs  i  \S  i-l[R]] 


cs  i  ;  5  i  - 1 


w 

cs  i:  K  [“£  —  l]^a[i]  A  R  )  V 

(a[i-l]>a[ij  A  swap  i  \R]i-lti)) 


clock 
clock —c 


if  a[i  -  l]>a[i]  then  swap  i  fi 
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swapi:  \(R  i-u)clock-sl 

t  [i]:=a[i  —  1] ;  a  [i  —  l]:  =  a  [i] ;  a[i]:  =  <[i] 

IR] 


A  j*i  — 1.1,2  + 1:  cs  i  j|  cs  j 

The  recursive  expression  for  Si\R]  will  suffice  for  our  purposes.  The 
independence  declaration  holds  globally  because  its  operands  obey  the  indepen¬ 
dence  theorem  of  Sect.  4.3.1:  for  \i  —  j|>  1 ,  cs  i  and  cs  j  do  not  share  any  vari¬ 
ables. 


The  properties  of  sort  n  can  be  stated  precisely  but  awkwardly.1"  sort  n  }R  j 
lists  every  permutation,  its  execution  time,  and  the  conditions  under  which  it 
must  be  applied  to  sort  the  array;  e.g.,  for  a  three-element  array  (n= 2)  the  fol¬ 
lowing  weakest  precondition  can  be  formally  derived: 


sort  2  [R  j 


c  lock 

~  (  (a[°]^a[l]^a[2]  A  ^)ciocfc_3c 

dock 

V  (a  [0]£a  [2]<a  [1]  A  R  ,  8)  clock^c  _s 

clock 

V  (a[2]<a[0]Sa[l]  A  (R0  ,),  2)  clack  _3c  _2s 

V  (a[l]<a[0]£a[2]A  R0.  i)  clock -3c  _s 

clock 

V  (a[l]Sa[2]<a[0]  A  {R  i,  2)o.  l)  cioc£  _3c  _2s 

cl  ock 

V  (a[2]<a[l]<a[0]  A  ((R0_  1)1. 2)0. 1)  cLock  _3c  _3s  ) 


The  next  lemma  presents  the  semantics  of  sort  n  as  a  predicate  in  the  vari¬ 
able  71. 

Let  II*  denote  the  set  of  permutations  of  (0.  1  with  1*  as  identity. 

Define  for  any  permutation  , 

t  The  use  of  permutations  is  awkward  in  the  inductive  assertion  method.  Hints  for 
specifications  which  enable  easier  proofs  are  in  [GeYe76]. 
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k  «**  R(a;  0,...,k:  a[rrJt(0)] . a[7T*(fc)]) 


a 


ord(a[0..fc])  =<u  /\(0^i<j^k  3a[i]^a[;']) 


R\k=R.  ord(a  [0..A:  ])  says  that  subarray  a [0..A; ]  is  in  orders. 
ord(a[0..fc  ])njfc  says  that  a[0..fc]  is  in  order  ^  after  permutation  rk. 


Lemma: 


For  semantic  R, 


A  (  sort  k  \R  j 

k>  0 


V  (ord(a[0..A:])A/?  )n  ) 

n*€llfc 


Proof: 


swap  i  represents  the  permutation  <r£:  (0 t...,i  —  l,ii...,k)  |— >  ( 0,...,i,i  —  l,...,k )  , 
i  =  l ,...,k  .  Define  additionally  v*  =df  1* .  Let  E4.cn*  be  the  set  of  permuta¬ 
tions  □*  performed  by  a  sequence  of  strictly  decreasing  swaps: 

=df  (  o’*  !  o’*  =  .  OSjiSk,  ISiSI,  lSISk. 

Induction  on  k: 

Base:  S0\R\  =  R  ,  sort  0[R\  =  R 

in d.  hyp.:  S  k\R]  =  V  (ord(ct[0..A;  ])  A  R  )a. 

ckG2k  * 


sort  k  [R  $  =  V  (ord(a  [0..A:  ])  /\R  )n 

TT _  cn  t 


*kGuk 


ind.  step:  =  cs  k  + 1  k  ]] 

=  (a [A:  ]^a [fc  + 1]  A  5  k\R))  V  (a[fc  ]>a[fc  +  l]  A  5  *  | R  \k,  jt+i) 

=  (a[fc ]^a[fc  +  1]  A  V  (ord(a[0..fc])  A  R  )~)  V 

ck<xk  * 

(a[fc]>a[A;  +  l]  A  (  V  (ord(a [0..fc  ])  A  R  )a  )k,k+i) 

okGi,k 

55  V  (ord(a[0..fc  +  1])  A  R  )a 

afc+i€i:jfc+i 

sortk  +  l\R\  =  sort  k  ;  S  k  +  l\R  \  =  V  (ord(a[0..fc  ])  A 

V  (ord(a[0..fc  +  l])A^)„  )„ 

*  1 

-  v  (ord(a[0..fc  +  l])Ai?)w 

wJfc  +  lcn*+l  k  +  l 

To  explain  the  last  identity:  every  permutation  7r*  +  i  can  be  written  as 
a  composition  and  vice  versa. 


-  41  - 


sort  n  sorts  any  n  +  1  elements  on  which  ^  is  a  total  ordering.  Thus  it 
satisfies  the  semantic  specification  of  Sect.  3.3  and  sorts  any  n  +  1  numbers: 


sort  n.  pre 


3  V  ord(a[0..n])n 

*»€nn 

=  V  ord(a  [0..n])n  A  perm(a,a) 

=  V  (ord(a.  [0..n  ])  A  permfa,  a' ))TT 
=  V  (ord(a[0..n])  A  ord(a  [0..n])  A  perm(a,a')), 
=  sort  n  \sort  n.  post} 


We  do  not  have  to  know  the  time  properties  of  sort  n  for  every  array  input. 
An  execution  time  for  a  worst-case  input  will  do  because  we  specified  only  a 
worst-case  requirement. 

The  following  lemma  provides  the  worst-case  execution  time  for  refinement 
sort  TL. 


Lemma: 

A  T(sort  k)  ^  c s 

fcso  v  '  2 

Proof: 

Induction  on  k : 


Base:  T(S0)  =  0,  T(sort  0)  =  0 

ind.  hyp.:  T (Sk)^k-c-s,  T (sort  Ic  )  g c •  s 


ind.  step:  T(S  k  + 1)  ^  max(l»  l+TC-S1  k))  £  (l+k)- c -s  , 

T (sort  k  4- 1)  =  T (sort  k )  +  T (S  k  +  1) 

S(kik±ll  +  x+k).c.s=  (k  +  l)(k+2),c. 


The  assumption  that  every  cs  i  has  to  swap  yields  equalities  every¬ 
where  in  the  proof:  the  time  bound  is  exact  for  an  array  input  in  decreas¬ 
ing  order. 

k(k  +  i) 

The  refinement  alone  does  not  satisfy  the  time  specification:  — L ■ c  s  is 

G(k2).  To  verify  that  the  independence  declaration  decreases  the  execution  time 
sufficiently  we  have  to  use  the  trace  proof  system  (Chap.  5). 
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5  The  Computations  of  a  Program  (The  Trace  Proof  System) 


In  the  previous  chapter  we  have  developed  a  proof  system,  the  refinement 
proof  sjrstem,  which  can  describe  the  properties  of  refinements  and  suggest 
different  computations  with  identical  semantics.  We  now  turn  to  a  more  power¬ 
ful  proof  system,  the  trace  -proof  system,  which  can  describe  these  computa¬ 
tions.  It  will  serve  to  formalize  the  effects  of  semantic  declarations  on  the  set  of 
computations  of  a  refinement. 

We  represent  the  computations  of  a  program  by  sets  of  directed  graphs 
called  traces.  (In  fact,  each  trace  still  represents  a  set  of  computations,  i.e.,  is 
rather  a  simpler  program.)  The  trace  set  T  (S )  of  refinement  51  contains  the 
computations  as  prescribed  by  S  with  composition  interpreted  as  sequential 
execution.  Semantic  declarations  D  eD  for  5  transform  its  trace  set  and  any 
trace  set  derived  by  a  previous  transformation  into  a  semantically  equivalent 
trace  set.  The  transitive  closure  of  all  these  transformations  contains  the  com¬ 
putations  of  the  semantic  version  SD  of  refinement  S'.  The  goal  is  to  create  a 
transformation  that  satisfies  not  only  the  semantic  but  also  the  time 
specification  of  the  problem. 


5.1  Trace  Sets 

In  this  section  we  will  describe  the  trace  set  T(S)  of  a  refinement  S,  i.e., 
the  set  of  computations  as  prescribed  by  S. 

Definition: 

A  trace  t  is  a  finite  directed  connected  acyclic  graph  with  the  follow¬ 
ing  properties: 

The  node  set  of  r  comprises  instances  of  basic  statements  and  guards 
in  RL,  plus  concurrent  command  nodes,  <  9  >  ,  where  rl  and  t2  are  two 

i 
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j-  ^ 

traces,  called  the  tines  of  <C  Tg  >  .  All  nodes  have  indegree  1  and  outde- 
grcc  1,  i.c.,  a  trace  is  a  sequence. 

A  directed  arc  between  two  nodes  vl  and  v2,  vl  —>v2  ,  is  an  output 
arc  of  vl  and  an  input  arc  of  v2.  An  arc  is  called  an  entry  {exit)  arc  of  t  if 
it  is  not  an  output  (input)  arc  for  any  node  in  r. 

We  can  compose  traces  rl ,  r 2  in  sequence  to  rl  — >  t2  by  merging  the 
exit  arc  of  rl  and  the  entry  arc  of  r2. 

Concepts  for  traces  can  be  applied  to  trace  sets  in  the  usual  fashion: 
for  trace  sets  T1 ,  T2, 

T1  — >  T2  =dr  [rl  ->t2  |  rl  €77,  r2€T2  J 
<££>  =«  (  <r2>  I  Tl  €”.  t2<lT2  j 

We  may  sometimes  not  take  the  trouble  to  distinguish  a  one-element  set 
and  its  element,  and  omit  the  entry  and  exit  arc  when  spelling  out  a  trace. 

The  trace  set  of  component  C  contains  the  computations  as  prescribed  by  C 
with  composition  interpreted  as  sequential  execution: 

Definition  (Computation  Rules): 


The  trace  set  T(C )  of  component  C  is  of  the  following  form: 


(CO) 

guard: 

T(B)  =*,  [B  J 

(Cl) 

null: 

7*  (skip)  =«  fskipj 

(C2) 

assignment: 

(a)  simple: 

Cq 

II 

H 

II 

65 

II 

eC 

(b)  subscripted 

:  T(x[Bl]:=B2)  =dr  \x[K1  ]:=B2 ( 

(C3) 

composition: 

T(S1 ;  S2 )  =„,  T(S1 )— >  T(S2 ) 

(C4) 

alternation: 

T(it  B1  -*S7  1  ...  $Bn  ->  Sn  0)  =d,  U  (r(fli)H»  T(Si)) 

•>  rr  1 
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(C5)  refinement  call:  (call  Sd  with  actual  indices  6  of 

refinement  Si):  SL  with  formal  indices  y ) 


(a) 

no  recursion: 

T(S$) 

=dt  T(SL) 

(b) 

(direct)  recursion: 

T(se) 

=dJ  u  T((se)t) 

no 

where  (Sl))o-  abort, 

(i>0)  (S^:  Sl^,k_r 

and  fail:  T  (abort)  =df  </> 

Examples: 

(1)  7"  (  if  x  *  0  -»  x :  =  0  d  x  =  0  ->  skip  fi)  =  |  x*0  x:  =  0,  x  =  0  — >  skip  } 

(2)  T  {fact  n)  =  \  n  =0  — >  r:~  1, 

n> 0  — >  77,-0  — >  r :  —  1  — >  r'.—r  n. , 

>0  ->  n  >  0  >  7i  —  0  — >  ?'  :  =  1  — >  r  :=r  n  — >  r:=r  n  , 

The  traces  of  a  refinement  51  do  not  reflect  its  refinement  structure:  they 
contain  only  basic  components.  Of  course,  the  traces  of  a  refinement  do  not 
contain  concurrent  commands  -  composition  is  translated  to  sequential  execu¬ 
tion. 

Traces  do  not  contain  alternations,  only  guarded  commands.  The  selection 
of  a  guarded  command  from  an  alternation  in  RL  corresponds  to  the  selection  of 
the  trace  that  contains  that  guarded  command  from  the  alternation’s  trace  set. 
(Remember  that  RL  programs  reflect  options  while  traces  reflect  decisions.) 

The  traces  of  indexed  refinements  contain  formal,  not  actual  indices.  The 
trace  set  semantics,  to  be  defined  next,  will  attribute  to  every  occurrence  of  a 
formal  index  in  a  trace  the  actual  index  value  established  by  the  most  recent 
call. 


Let  us  now  describe  the  properties  of  the  trace  set  T(C )  of  component  C  by 
trace  rules  similar  to  the  language  rules  for  RL  (see  Sect.  4.2.1): 
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Definition  (Trace  Rules): 

For  all  timed  assertions  R  and  some  implementation-dependent 
integer-valued  function  A: 

clock 

(TO)  guard:  T(B)\R\  ^  B  A  Rclock_r{B ) 

(Tl)  null:  T(skip)[R]  R 

(T2)  assignment: 

(a)  simple:  T (x :=£)(/?  (  clock„r{Ey^ 

(b)  subscripted:  T  (x[E1  ]:=E2  )\R] 

x,  clock 

R(x ;  El  :  E2),  clock -T(E1  )-T(E2)-A:= 

(T3)  composition:  T(S1  ;  S2  )\R  j  =dr  T(S1  )\T(S2)[R]\ 

(T4)  alternation:  7*(  if  D1  -*  SI  0  ...  |]  Bn  ^  Sn  fi)$R  $  =<u 

Ti  clock 

(  V  ( Bi  A  T(Si)\R\)  )ciock-T(B1 Bn )-Aj, 

(T5)  refinement  call:  (call  5?  with  actual  indices  c?  of 

refinement  Sij:  SL  with  formal  indices  $) 


(a)  no  recursion: 

(b)  (direct)  recursion: 

where 

(i>0) 

and  fail: 


clock 

T(se)m  =dJ  nsL)m3  cl0Ck_m_^ 
T{SS)\R\  =4,  vr((if),)|«| 

i20 

(Sy)0:  abort, 

<S^'-  Ki),:-,- 

7* (abort) fR  j  =&  false 


Definition: 

The  execution  lime  T(T(C))  of  the  trace  set  of  component  C  is 

T  (T(C))  =df  r(C)fciocfc^Ojtims 


The  following  theorem  states  that  a  refinement  and  its  trace  set  have  ident- 
ical  properties.  This  identity  is  crucial.  It  ensures  the  compatibility  of  our  two 
proof  systems:  whatever  a  refinement  represents  in  the  refinement  proof  system 
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is  properly  represented  by  its  trace  set  in  the  trace  proof  system. 

Theorem: 

For  all  refinements  5  and  timed  assertions  R,  T{S)\R]  =  51  [R  }  . 

Proof: 

The  identity  is  directly  evident  by  comparison  of  language  rule  (Li) 
with  trace  rule  (Ti),  2  =  1,...,  5. 

We  have  defined  the  trace  calculus  in  terms  of  trace  sets  which  are  derived 
from  refinements.  This  permitted  a  trivial  transformation  of  the  refinement  cal¬ 
culus  into  a  calculus  for  traces:  language  rules  (LI)  to  (L5)  and  trace  rules  (Tl) 
to  (T5)  are  identical.  However,  what  is  really  needed  is  a  calculus  for  traces 
independent  of  their  derivation.  Hoare’s  operational  definition  of  the  weakest 
precondition  operator  for  traces  [Hoa?8a]  provides  such  a  calculus  and  is  con¬ 
sistent  with  our  trace  rules. 


5.2  Semantic  Transformation  of  Trace  Sets 

Semantic  declarations  add  computations  for  51  as  described  informally  in 
Sect.  2.2.2.  Formally,  a  set  D  of  semantic  declarations  for  refinement  5 
transforms  the  refinement’s  trace  set  T(S)  or  a  previous  transformation 
thereof  into  a  new  trace  set.  The  transitive  closure  T(SD)  of  all  such  transfor¬ 
mations  contains  the  computations  for  the  semantic  version  SD  of  S. 

We  will  see  that  all  trace  sets  in  T(SD)  have  identical  semantics:  the 
semantics  of  S.  We  call  a  trace  set  with  the  semantics  of  S  a  trace  set  for  S. 
T(S)  is  the  unique  trace  set  of  S.  We  do  have  a  rule  for  the  sequential  composi¬ 
tion  of  traces,  given  by  (T3)  and  (C3).  But  some  of  the  transformed  trace  sets 
will  contain  concurrency,  and  we  need  one  more  trace  rule  that  describes  the 
properties  of  concurrent  composition: 
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Definition  (Additional  Trace  Rule): 

/ 

(T6)  concurrent  command:  -df  c/Hfl!umC2  A 

qIoc 

(  (T(Cl)->T(C2))[R„m]  .  T{C1  Mourns)  A  T(.C2)\Rtim»)  )  docfc— &<> 

The  semantics  of  a  concurrent  command  are  sequential:  those  of  any  inter¬ 
leaved  computation.  The  full  commutativity  included  in  the  independence 
requirement  guarantees  that  all  interleaved  computations  have  the  same  pro¬ 
perties  (semantics  and  execution  time). 

The  execution  time  of  a  concurrent  command  is  the  maximum  of  the  execu¬ 
tion  times  of  its  tines,  plus  some  constant  A<>  that  accounts,  e.g.,  for  processor 
management.  The  non-interference  included  in  the  independence  requirement 
guarantees  that  both  tines  can  be  executed  in  parallel  without  delays.  (We 
disregard  delays  due  to  indivisible  memory  reference.) 

With  trace  rule  (T6)  we  have  the  means  for  expressing  parallelism  and  can 
turn  to  the  formal  description  of  the  effects  of  semantic  declarations.  A  seman¬ 
tic  declaration  transforms  a  trace  set  by  replacing  parts  of  certain  traces  in  it. 
To  identify  these  parts,  we  use  the  concept  of  a  subtrace  set: 

Definition: 

(a)  T1  is  a  subtrace  set  of  trace  set  TZ, 

T1  E  TZ  —At  V  TZ  -  7*h->  T1  -$>  Tt 
Th,  7\ 

(b)  T1  is  a  subtrace  subset  of  trace  set  T2, 

TI'QCTZ  Stf  V(nET  A  TQT2) 

T 

If  <  >ECjr  ,  then  T'  and  T  "  are  called  tine  sets  of  T. 

Because  we  transform  program  components  into  trace  sets  we  are  pri¬ 
marily  interested  in  trace  sets,  not  traces,  and  subtrace  sets,  not  subtraces  - 
although  a  subtrace  set  with  only  one  element  can  be  regarded  in  place  of  a  sub¬ 
trace.  According  to  our  definition,  a  collection  of  subtraces  does  not  necessarily 
constitute  a  subtrace  set.  We  require  that  a  subtrace  set  can  be  isolated  by 
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trace  set  composition,  an  operation  which  in  mathematically  complex  fashion 
mutually  connects  all  members  of  the  sets  involved.  Program  components  can 
always  be  isolated  this  way,  and  our  trace  sets  are  derived  from  program  com¬ 
ponents.  Again,  a  calculus  independent  of  the  derivation  from  programs  could 
be  presented,  but  it  would  be  more  complicated. 

The  tine  sets  of  trace  set  T  are  not  subtrace  subsets  of  T.  In  particular,  the 
tines  of  trace  t  are  not  subtraces  of  t.  A  trace  is  a  sequence  of  nodes.  To  know 
all  operations  of  trace  t,  we  have  to  look  at  the  nodes  of  t  and,  if  we  encounter  a 
concurrent  command  node,  look  recursively  at  the  nodes  of  its  tines. 

Now  that  we  can  identify  parts  of  traces  and  trace  sets,  let  us  formalize  the 
substitution  of  one  part  for  another.  Of  the  following  definition,  part  (a)  deals 
with  subtraoe  subsets,  part  (b)  describes  the  recursive  treatment  of  concurrent 
commands: 

Definition: 


77 


(a)  If  T  is  a  trace  set,  T is  T  with  subtrace  (sub)set  77  replaced  by  trace  set 


Th->T2^Tt  if  V  T  =  Th->T1  ->  7*t  (i.e.,nE7) 

Jo,,  7\ 


77 


T1 

( T\T')uT’T2  if  yT/Er’CT1  (i.e.,  T1  QcT) 


T 


otherwise 


77 


t  '  77 

For  concurrent  commands, 


(b)  Trace  set  T'  is  T  with  T1  in-place  of  T2  iff 

77 

(i)  T'  =  Tpg,  or 
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(ii)  7*par  is  a  concurrent  command  in  T,  and  7”  is 

T1 

T  with  (7* par) 7^  in  place  of  7*par. 

We  will  use  the  notion  "T  with  T1  in  place  of  TZ"  to  let  semantic  declara¬ 
tions  transform  trace  sets  by  replacement  of  certain  of  their  activities.  But  first 
we  have  to  identify  which  trace  set  parts  ought  to  be  replaced,  i.e.,  wTe  have  to 
select  those  components  in  the  trace  set  that  match  the  semantic  declaration. 

In  the  subsequent  definitions  we  consider  a  refinement.  S,  instances  cl ,  cl' 
and  c2  of  components  Cl  and  C2  of  S,  a  semantic  relation  Z  involving  Cl  and 
C2 1",  and  its  declaration  D  under  enabling  condition  P  and  for  result  condition  R. 

To  find  out  for  which  parts  of  trace  set  T  declaration  D  applies,  we  proceed 
in  three  stages.  First,  we  find  all  instances  of  components  Cl  and  C2  in  T.  Then 
we  select  those  instances  that  are  adjacent.  Only  adjacent  instances  can  be  can¬ 
didates  for  a  semantic  transformation.  Finally  we  check  the  scope  in  which 
every  candidate  appears,  i.e.,  inspect  the  pre-  and  postcondition  of  every  adja¬ 
cent  instance  pair.  We  may  consider  performing  a  transformation  only  if  the 
scope  of  the  declaration  is  matched,  i.e.,  if  the  precondition  implies  the  enabling 
condition  of  the  declaration  and  the  postcondition  is  implied  by  the  result  condi¬ 
tion  of  the  declaration. 

Definition: 

(1)  The  instance  set  It(C)  of  component  C  in  some  trace  set  T  is 

7y(C  )  =df  {  c  |  c  is  an  instance  of  C,  and  T (c )  Ec  T 

or  c  e/y(C)  for  some  tine  set  T'  of  T  j 


t 


For  idempotence  7.  involves  only 


Cl all  definitions  apply  without  consideration  of  C2. 
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/r(C)  is  the  set  of  all  component  instances  of  C  appearing  in  T. 

(2)  With  respect  to  some  trace  set  T,  relation  Z  can  be  interpreted  as 

ZT  =df  \{c1,c2)  \  T(c1  )->T(c2)\CqT  or  T(c2)-^>  T (cl  )QQ  T 

or  (c1,c2)eZr  for  some  tine  set  T"  of  T, 

(cl  ,c2)  €-It(C1  )xIt(C2)  { 

(c1,c2)eZT  is  a  candidate  for  Z  in  T.  A  candidate  is  a  component  pair  in  T 
which  matches  the  operands  specified  in  relation  Z. 

(3)  With  respect  to  some  trace  set  T  with  proof,  declaration  D  can  be  inter¬ 
preted  as 

DT  =61  \  (cl  ,c2)  \  pre(T(c1  )-j>T(c2))dP  , 

R  Dpost(7*(c7  )—>  T(c2)),  (c1,c2)€Zt  $ 

(cl ,c2)  € Dy  is  an  applicator  of  D  in  T.  An  applicator  is  a  candidate  in  T 
which  appears  in  the  scope  specified  in  declaration  D.  D  with  Cl,  C2 
replaced  by  cl ,  c2  is  the  declaration  instance  d  of  D  at  applicator  (cl ,c2). 
An  ih-line  declaration  indicates  the  location  of  some  of  its  instances. 

Dt  QZj  QIt(C1  )x/y»(C2). 

At  last,  we  are  ready  to  perform  a  semantic  transformation!  We  can  isolate 
in  T  an  applicator  (cl ,c2)  of  declaration  D  and  define  the  effect  of  declaration 
instance  d  at  (cl ,c2).  d  generates  from  T  its  transformation  7": 

Definition  (Generation  Rules): 

The  declaration  instance  d  of  D  at  (cl ,c2)  generates  T'  from  T  iff 

(G'l)  d  is  l cl  ,  and  T'  is  T  with  T(c1  )  in  place  of  7'(c/  )—>  T(c1  ') , 

or  vice  versa,  or 

(G2)  d  is  cl  & c2  ,  and  T'  is  T  with  T(c2)—>  T(c1  )  in  place  of 

7’(c7  )— >  T(c2  ),  or  vice  versa,  or 
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(G3)  d  is  cl  ]]  c2  ,  and  (for  arbitrary  T")  T'  is  T 


i 

with 

in  place  of 

either  (i) 

or  (ii) 

or  (iii) 

'•  T(c2)  ' 

T(cZ) 

'■  T  (c2)  > 

T{c1  )— >  T (c2  ) 
or 

T(c2)->T(c1  ) 
T(c1  )->  <  TJc2)  > 

<  T(cZ)  >  T(~c1  > 

or  some  subsumed  commutativity  or  independence  gen¬ 
erates  T'  from  T. 

There  must  be  three  rules  for  the  development  of  concurrency  (G3):  one  to 
create  concurrent  commands  (i),  and  two  to  extend  already  existing  concurrent 
commands  to  the  right  (ii)  and  to  the  left  (iii). 

Definition: 

(a)  Semantic  declaration  instance  d  generates  T '  from  f  iff  d  gen¬ 

erates  T'  from  some  7\  . 

(b)  Semantic  declaration  D  generates  T'  from  T  iff  some  declaration 
instance  of  D  generates  T'  from  T. 

We  can  now  describe  the  computations  of  semantic  version  SD.  We  have  to 
build  the  transitive  closure  of  all  transformations  of  trace  set  T(S)  by  semantic 
declarations  in  D. 

Definition: 

The  transformation  set  T(SD)  of  semantic  version  SD  is  defined  induc¬ 
tively: 

T0(SD)  =df  \T(S)) 

(i>  0)  Ti(SD)  =dj  Ti-i(SD)  u  {  TD  |  \Z^  D  generates  TD  from  Ti-\{SD)  j 

T(SD)  =df  U  Ti(SD) 

i  20 

For  all  z>0,  Ti-i(SD)  Q  Tr(SD).  In  the  absence  of  recursion  T(SD)  is  finite: 
there  is  a  k  such  that  Ti-i(SD)  =  Ti(SD)  for  iZk,  indicating  that  further 
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applications  of  semantic  declarations  do  not  generate  new  trace  sets.  If  ZJ=0, 
then  T(SD  )  =  \T(S)] ;  thus  5  0  is  S. 

We  want  to  prove  that  the  transformation  of  a  trace  set  does  not  alter  its 
semantics,  i.e.,  that  every  trace  set  in  T(SD )  has  the  semantics  of  5.  We  have, 
in  the  refinement  proof  system,  defined  semantic  relations  for  refinement  com¬ 
ponents.  However,  now  we  are  in  the  trace  proof  system  and  are  dealing  with 
trace  sets,  not  with  refinements.  We  must  characterize  semantic  relations  in 
terms  of  trace  sets. 

The  next  lemma  does  just  this.  It  can  be  viewed  as  justification  for  our 
choice  of  generation  rules.  The  lemma  implies  that  the  transformation  of  a  trace 
set  does  not  alter  its  semantics,  and  the  following  theorem  concludes  induc¬ 
tively  that  all  transformations  of  T(S)  must  have  the  semantics  of  T(S),  i.e., 
the  semantics  of  5. 

Lemma: 

For  any  components  C,  Cl ,  C2,  and  semantic  assertion/?, 

(a)  !rC  ee  (T(C)\R]  =  (T{C)->T{C))\R\) 

(b)  C1ScrC2=  ((T(Cl)-^T(C2)){R]  =  (T(C2)-^>T(C1))\R]) 

(For  semantic  purposes,  independence  reduces  to  full  commutativity,  which 
is  defined  in  terms  of  commutativity.) 

Proof: 

For  statements  S,  SI ,  S2,  and  guards  B,  D1 ,  B2,  and  semantic  assertion/?, 

(a)  !rB  =  true  =  ( BAR  =  BA{BA,R )  ) 

=  (  T(B)\R]^  (T(B)->T(B))\R]) 
!rS  =  (S{R]  =  S-.SIR]  )  =  (  T(S)  =  (T (S ) ->  T (S  ))\R  ]  ) 

(b)  B1  &rB2  =  true  =  (  B1  A(B2AR)  =  B2A(B1  AR)  ) 

=  (  (T(B1  )->T(BZ))[R]  =  (T(B2 }— >  T(B1  ))\R  J  ) 
S&rB  a  (BAS[R]  =  S'lBAR]) 

=  (  (T(B)->T(S))[R]  a  (T(S )— >  T (B  )){R  ]  ) 
S1&rS2  =  (SI  \S2\R]  =  S2-S1  \R\) 

=  (  (T(S1  )— >  T(S2  ))\R  i  a  (T(S2  )— >  T(S1  ))\R]  ) 
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Theorem: 

For  any  semantic  version  SD  and  any  semantic  assertion  R, 


Proof: 


A 

7  e  r  (SD ) 


T{R]  =  S\R] 


Induction  on  the  number  of  transformations: 

Base:  D  -  0  ,  T  (SD)  =  [T  (S)] ,  T(S)\R]  =  S\R]  (previous  theorem). 

ind.  hyp.:  Assume  an  nth  transformation  T  of  T  (S  ),  and  T\R\  =  S\R\. 

ind.  step:  Let  some  dcD  generate  T'  from  T.  Since  the  weakest  precondi¬ 
tion  of  the  subtrace  set  in  T  which  d  replaces  and  its  substitute 
are  in  all  cases  identical  (previous  lemma),  T'  has  the  same 
semantics  as  T.  Thus  T'[R  $  =  S'  [R  ] . 


The  semantics  of  different  trace  sets  for  S'  are  identical,  but  their  execution 
times  will,  in  general,  differ  (otherwise  the  semantic  declarations  were  point¬ 
less).  To  make  the  semantic  version  a  solution  to  the  problem,  at  least  one 
trace  set  has  to  stay  within  the  specified  time  limit: 

Definition: 

We  let  \P,t }  SD  \R  ]  stand  for  an  argument  that  establishes  the  truth 
of  the  formula  (P,l)  T  [R,  0]  for  some  trace  set  T  eT  ( SD ) ,  i.e.,  a  proof  of 
total  correctness  with  respect  to  specification  ( P,R,t )  for  some  transfor¬ 
mation  of  T  {S  )  by  D. 

The  previous  theorem  allows  us  to  check  semantic  correctness  of  SD  by 
proving  the  refinement  S'.  However,  in  order  to  fulfil  a  time  requirement,  we 
may  bo  forced  to  search  T(SD)  for  a  suitable  transformation.  This  problem  is 
addressed  in  Chap.  6. 

To  conclude  this  section,  let  us  investigate  the  computational  equivalence  of 


semantic  versions: 
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Befmition: 

We  call  two  semantic  versions  S1D1  and  S2D2  of  refinements  SI  and 
S2  basically  equivalent,  and  write  S1D1  —  S2D2  iff  S1D1  and  S2D2 
have  the  same  transformation  sets,  i.e.,  T(S1D1  )—T  (S2D2 ) . 

The  case  D1  -D2  =0  provides  a  definition  of  basic  equivalence  of 
refinements. 

Basically  equivalent  refinements  must  have  the  same  potential  for  con¬ 
currency: 

Lemma: 

Consider  twro  basically  equivalent  refinements  SI  and'S*?. 

For  every  set  D1  of  semantic  declarations  for  SI  there  is  a  set  D2  of 
semantic  declarations  for  S2  such  that  S1D1  -S2D2  . 

Proof: 

li  D1  —  0  set  D2=M<p. 

Otherwise,  for  all  declarations  DIzDI  ,  D1  can  be  replaced  by  the 
sequence  of  all  declaration  instances  dil  of  D1  in  T(S1D1),  yielding  a 
declaration  set  D1  '  such  that  S1D1  =S1D1'.  (Joining  the  declaration 
instances  at  calls  of  a  recursion  into  a  set  declaration  keeps  D1  '  finite.)  By 
expanding  refinement  calls  we  can  transform  D1  '  into  a  set  D1  "  of 
declarations  each  of  which  only  involves  concrete  components; 
SI D1  ”  =  S1D1  ’ .  Since  basically  equivalent  refinements  have  identical 
trace  sets,  D1  "  has  identical  effects  on  SI  and  S2.  Set  D2  =d jDI 

Although  SI D1  and  S2D2  may  be  basically  equivalent,  one  may  be  prefer¬ 
able  to  the  other:  the  conciseness  with  which  the  semantic  relations  in  a 
refinement  can  be  described  depends  on  the  refinement  structure.  There  may 
also  be  refinements  basically  different  from  SI  and  S2  that  satisfy  the  semantic 
specification  and  have  better  concurrency  properties. 

The  trace  proof  system  can  describe  the  properties  of  a  semantic  version 
SD.  It  can  tell  whether  SIJ  is  a  solution  to  the  specified  problem,  but  not 
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whether  it  is  an  optimal  solution  or  what  an  optimal  solution  will  look  like.  Our 
methodology  emphasizes  the  development  of  safe,  not  of  optimal  programs. 


5.3  Program-Specific  Semantic  Declarations 

The  purpose  of  enabling  and  result  conditions  in  semantic  declarations  is  to 
determine  the  applicators  of  a  declaration  among  the  candidates  for  the 
declared  relation.  However,  it  may  be  that  the  enabling  or  result  condition  of 
some  declaration  is  satisfied  by  all  candidates  and  therefore  irrelevant  for  the 
program  in  which  the  declaration  appears.  An  obviously  irrelevant  condition  may 
be  omitted,  rendering  the  declaration  pTognnn-srpucific  -  applicable  only  to  that 
program  in  which  the  condition  is  superfluous. 

Definition: 

(1)  Consider  a  trace  set  T  and  a  semantic  relation  Z  with  scope  ( P',R ’).  If 
[P  j  T  [R  }  is  a  proof  with  respect  to  semantic  specification  ( P,R  ),  define 

(i)  POST(P')  as  the  conjunction  of  all  postconditions  of  candidates 
for  Z  in  T  which  have  a  precondition  implying  P\ 

(ii)  PRE(R’)  as  the  disjunction  of  all  preconditions  of  candidates  for 
Z  in  T  which  have  a  postcondition  implied  by  R\ 

(a)  Z  is  gener  al  under  P'  in  T  with  respect  to  ( P,R )  iff  there  is  a 
proof  \P\  T  JA! }  such  that  R’  D  POST  (P' ) . 

(b)  Z  is  unconditional  for  R}  in  T  with  respect  to  { P,R )  iff  there  is  a 
proof  \P\  T  \R\  such  that  PRE(R')^P'  . 

(c)  Z  is  global  in  T  with  respect  to  ( P,R )  iff  there  is  a 

proof  [P\  T  [R\  such  that  R' D  POST  (true)  and  PRE  (false)  3P'  . 

(2)  Consider  a  semantic  version  SD  where  D  declares  relation  Z  for  scope 

(. P\R '). 
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Z  is  general  under  P  (unconditional  for  R' ,  global)  in  SD  ifT 
Z  is  general  under  P'  (unconditional  for  R' ,  global)  in  every  T  £  T(SD  )  . 

Relations  that  hold  generally  (unconditionally,  globally)  in  SD  may  be 
declared  like  general  (unconditional,  global)  relations,  i.e.,  in  declarations 

(i)  the  result  condition  may  be  omitted  if  Z  is  general  in  SD, 

(ii)  the  enabling  condition  may  be  omitted  if  Z  is  unconditional  in  SD, 

(iii)  the  enabling  and  result  conditions  may  be  omitted  if  Z  is  global  in  SD. 

If  the  generality  (unconditionality,  globality)  of  a  relation  in  SD  can  easily 
be  detected  much  effort  may  be  saved:  the  checking  of  intermediate  assertions 
in  the  traces  in  order  to  identify  certain  candidates  as  applicators  becomes 
unnecessary.  For  a  semantic  relation  global  in  SD  every  candidate  is  an  applica¬ 
tor. 

5.4  Example:  Sorting 

We  have  to  look  at  the  transformation  set  of  the  semantic  version  of  sort  n 
presented  in  Sect.  2.3  and  investigate  if  some  transformation  of  the  refinement 
trace  set  T(sort  n)  satisfies  the  time  limit  of  0(n)  specified  in  Sect.  3.3. 

Our  trace  notation  has  been  designed  to  describe  the  effects  of  semantic 
declarations,  not  to  describe  specific  traces  or  trace  sets.  We  present  some  use¬ 
ful  new  notation  now,  but  leave  a  more  involved  syntax  for  concise  trace  proofs 
to  the  user: 


n 

—>  Ti  =df  Tt->  r2 rn 

a=i 


n 

<  T<  >  =df 

1=1 


Tl 


if  7i  =  l 


Ti  > 


n  — 1 


< 


i  =  l 


>  if  n>l 


n 
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The  computation  rules  transform  the  refinement  sort  a  into  the  following 
trace  set: 


n  i— 1 

T (sort  n )  -  (— >  T(cs  i-j )) 

t=l  j= o 

We  may  view  cs  i  as  a  basic  statement  because  the  independence  declara¬ 
tion  for  sort  n  does  not  refer  to  proper  components  of  cs  i.  This  allows  us  to 
interpret  trace  sets  for  sort  n  as  single  traces: 

n  i  —  1 

T (sort  n )  =  rn  =df 

i  =  l  j-Q 

e.g.,  for  a  five-element  array  (n=  4), 


t4  =  cs  1  cs  2  cs  1  ->  cs  3  ->  cs  2  ->  cs  1  ->  cs  4  ^  cs  3  ->  cs  2  cs  1 

We  proved  in  Sect.  4.4  that  the  worst-case  execution  time  of  rn  is  0{n2). 

We  will  now  prove  that.  rn  can  be  transformed  by  the  given  independence 
declaration  to 


_  n-i  n-i 

=d f  (r>  vi)  <7>  vn-i) 

1=1  1=0 

t-1 


where  =df  <^csi-2j^> 


1=0 


e.g.,  for  a  five-element  array. 


~  o  /  cs  3 

r <  =  CS  1  cs  2  <  s  J  > 


<•  cs  2  > 

^  cs  4  ^ 


<  CS  1  y 

^  cs  3  ^ 


cs  2  — >  cs  1 


If  we  neglect  processor  management  (A<>— 0^),  »n  has  a  worst-case  execu¬ 
tion  time  of  (2n-l)*c-s,  i.e.,  0{n).  rn  is  fastest  for  this  semantic  version  of 
sort  7i,  but  we  need  not  prove  that.  We  only  have  to  know  that  it  satisfies  the 
specified  time  limit. 

t  To  obtain  linear  execution  time  for  a  progriun.  with  unbounded  concurrency,  A<>  must 
be  negligible. 
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Lemma: 


For  all  n,  Tn  can  be  transformed  into  rn. 


Proof: 


Induction  on  rt: 


Base:  T\  =  rt  =  cs  1  (identity  transformation). 


ind.  hyp.:  Tn  cem  be  transformed  to  Tn. 

n  +  1  t-1  n  i-l  n 

ind.  step:  rn+i  =  —>  (—>  csi—j)  =  — >  (— >  csi—j)  — >  (— >  csi—j) 

i=l  j=0  t  =  l  j=0  j=0 

can  by  ind.  hyp.  be  transformed  to 

i-l 

n- 1  2 

T’n  +  l  =df  <csi-2j  >  ) 


i  =  l 


;=o 


n-i-l 


n 


n  — 1  2 

(— >  <  CS  71-1+27  >  )—>(—>  CS  71+1—?') 

t=o  i- o  i=o 

i-l 

n  2 

=  (— >  <C.csi-2j  >  )  — > 

i  =  l  j  =0 

n-i-l 

n-1  2  n 

(— >  <  CS  71 -l+2.;>  )->(->  CS  71+  1— J  ) 

i=l  3=0  j= 0 


The  inductive  step  is  to  show  that 

n-i-l 


n-1  2  n 

*n  +  l  =df  (->  <  CS  71  — 1+2.7  >  )->(->  CS  71+ 1-j) 

i=l  j=0  j=0 

* 

transforms  to 

n-i-l 

n-1  2 

An  +  i  =df  (— >  <  cs  71  +  2-1+2.;  >  )  cs  2->  cs  1 

i=l  j=0 

n—i 


n-2  2 

=  (  — ^  <  CS  71  +  1-1+27  >  )  —> 

i= I  7=0 


n-t 


n  2 

(  — >  <  cs  71  +  1— i  +  2j  >  ) 

t=n-l  j=0 


n  —i 


n  2 

— >  <  CS  71  +  1— 1  +  27  > 

t=0  j=0 
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Then  r'n  +  j  transforms  to 


i- 1 
2 


71  — < 


™  <5  71  £ 

T  'n  +  l  =df  (~>  <^csi-2j  >  )  — >  (— >  <  cs  n+  1—  i  +  2?  >  ) 

1=1  j =0  i=0  j-0 


=  T, 


n  +  1 


To  show  the  inductive  step,  let  us  define 


n-i-l 

n-1  2 

*n  + 1  =df  <  CS  71-1  +  27  > 

7=0 


1  =  1 
n 


/Ai+l  =df  ^  CS  71+  1 — jf 


n-i-l 


n-1  2 

^n  +  1  =df  ~ >  <C.  CS  n+2~i+2j  > 


1  =  1 


7=0 


Then  An+1  =  *cn+i  “>  A*n+i .  =  Jcn+1  ->  cs  2  ->  cs  1 . 

Remember  that  cs  i  ||  cs  j  for  \i—  j|>1.  With  k  =  l . n-1. 

the  highest  index  in  the  fcth  node  (concurrent  command)  of 
tcn+ 1  is  n-k,  the  index  of  the  fcth  node  of  /Ai+i  is  n-k+  2.  Note 
that  the  indices  in  both  fcn+1  and  /zn+ j  are  monotonically 
decreasing,  i.e.,  low  indices  in  /cn4-i  meet  high  indices  in  /Ai  +  i- 
Thus  the  fcth  node  of  /j^+i  can  be  commuted  to  the  fcth  con¬ 
current  command  of  tcn+t  (G2)  and  ravelled  up  as  a  new  tine 

(G3i).  Doing  this  for  all  k,  we  obtain  £n+1.  ^n+i  has  two  more 
nodes,  cs  2  — >  cs  1 ,  which  cannot  be  ravelled.  This  leaves  us 

with 


Tn  sorts  array  a[0..nj  in  2n-l  steps.  a[0..n]  can  be  sorted  faster,  in 
approximately  n  steps,  by  alternately  comparing  all  odd  pairs  in  parallel  and  all 
even  pairs  in  parallel,  n/2  times.  However,  the  according  trace 


(vodd  v 


even) 


where 


^odd 


=di  <  cs  2 j  - 1  > 


3=1 


^even  “df 


<  cs  2j  > 


71. 

2 

7  =  1 
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cannot  be  derived  from  our  refinement  of  sort  n,  not  even  if  we  additionally 
declare  the  idempotence  of  cs  i,  for  all  i.  The  trace  does  not  constitute  a  bubble 
sort.  For  computations  which  are  not  a  bubble  sort,  sort  n  must  be  refined 
differently. 


5.5  Operational  Models  for  Traces 

We  have  already  in  Sect.  5.1  referred  to  an  operational  representation  of 
traces:  the  exhaustive  study  of  Hoare  [Hoa76a].  Although  Koare  considers  only 
sequential  execution,  the  semantics  of  concurrent  command  rule  (T6)  are 
clearly  consistent  with  the  arbitrary  interleaved  execution  of  the  two  tines  in  his 
operational  model:  the  semantic  part  of  (T6)  is  the  weakest  precondition  of 
every  interleaved  execution. 

Operational  models  commonly  simulate  concurrency  by  interleaved  execu¬ 
tion,  but  if  we  want  to  model  execution  time  and  not  only  semantics  we  are  in 
need  of  truly  parallel  execution.  We  can  represent  it  by  tokens  propagating 
along  the  arcs  of  traces. 

Node  v  of  trace  t  is  activated  when  the  input  arc  of  v  carries  a  token.  Upon 
termination  of  the  node,  the  token  is  transferred  from  the  input  to  the  output 
arc  of  v.  If  a  guard  evaluates  to  false,  a  token  is  placed  on  an  imaginary  second 
output  arc  instead.  We  call  it  abort  arc  since  a  token  on  it  signifies  abortion  of 
the  trace.  Abort  arcs  are  exit  arcs.  Activating  a  concurrent  command  means 
placing  a  token  on  the  entry  arc  of  every  tine. 

A  call  of  a  refinement  S  places  a  token  on  the  entry  arc  of  every  trace  in  its 
trace  set  T (S).  If  a  token  reaches  the  exit  arc  of  its  trace,  that  trace  models  a 
legal  computation  for  this  call.  All  traces  are  simultaneously  executed  to  the 
point  of  termination  or  abortion. 

The  call  of  a  refinement  <5  with  semantic  declarations  D  can  be  modelled  by 
simultaneous  calls  of  all  trace  sets  TcT(SD ).  The  transformations  whose 
tokens  come  to  rest  first  are  fastest. 
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We  can  use  a  formalism  to  describe  the  safe  movement  of  tokens  as  defined 
by  Lamport  [Lam77j  for  a  set  of  N  concurrent  processes  built  from  nodes  of  two 
types:  assignment  and  decision.  Execution  is  modelled  by  the  transformation  of 
program  states  that  are  values  of  variables  paired  with  arcs  in  the  process 
graph.  Assertions  labelling  arcs  describe  the  legal  states. 

We  replace  Lamport’s  processes  by  traces  and  consider  only  the  cases  N  =  1 
modelling  sequential  execution  and  N  =  2  modelling  binary  concurrency.  Higher 
than  binary  concurrency  can  be  simulated  by  nested  binary  concurrent  com¬ 
mands. 

To  be  able  to  use  Lamport’s  formalism,  we  have  to  classify  trace  nodes  as 
assignments  and  decisions: 

(a)  basic  statements  (null  and  assignment)  and  concurrent  commands  are 

assignment  nodes, 

(b)  guards  are  decision  nodes  (remember  the  added  abort  arcs). 

Lamport  calls  a  mapping  of  an  assertion  on  each  arc  of  trace  r  an 
interpretation  I  of  r.  I  is  consistent  at  node  v  iff  PDv[R],  where  P  labels  the 
input  arc  and  R  the  output  arc  of  v.  I  is  consistent  iff  it  is  consistent  at  every 
node  of  r.  Any  set  of  intermediate  assertions  for  trace  t  derived  in  conformity 
with  trace  rules  (TO)  to  (T6)  is  consistent. 

Lamport  calls  an  interpretation  that  is  a  proof  for  t  with  respect  to  some 
semantic  specification  (P,R)  invariant  with  respect  to  P.  To  assure  the  con¬ 
current  correctness  of  two  tines  of  a  concurrent  command,  they  must  have 
invariant  interpretations  that,  are  mutually  monotone,  Lamport’s  term  for  con¬ 
sistency  on  shared  data.  Our  notion  of  independence  implies  Lamport’s  mono¬ 
tonicity. 

We  encourage  the  reader  to  study  Lamport’s  model  [Lam?7]  (the  formalism 
fills  only  one  page).  Lamport  does  not  consider  execution  time,  but  an  extension 
is  simple:  include  the  effect  of  nodes  in  the  hidden  variable  clock  (this  converts 
decision  nodes  into  a  second  type  of  assignment,  nodes),  but  disregard  clock  in 
monotonicity  arguments. 
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6  Implementation 


In  the  previous  chapter  we  have  described  a  semantic  version  SD  by  the 
transformation  set  T(SD).  Its  members  are  the  trace  set  T(S)  of  refinement  51 
and  a  number  of  transformed  trace  sets  with  the  same  semantics  as  T(S).  This 
chapter  discusses  the  implementation  of  SD,  i.e.,  the  selection  of  a  suitable 
trace  from  T  (SD )  for  execution. 

First  some  general  remarks: 

Executing  a  program  concurrently  is  not  going  to  be  simpler  or  cheaper 
than  a  sequential  execution.  It  is  going  to  be  faster,  though,  and  in  order  to  save 
time  in  execution  we  will,  in  general,  have  to  expend  additional  effort  previously. 

Let  us  assume  a  program  that  we  cannot  or  do  not  want  to  optimize.  How¬ 
ever,  we  want  it  to  take  less  time  than  it  does  if  executed  in  sequence.  To  keep 
the  length  of  the  execution  within  the  desired  limits,  we  have  to  ravel  the 
program’s  components  into  a  sufficient  number  of  concurrent  tines.  This  is  no 
improvement  of  the  program’s  computing  effort.  We  merely  choose  to  invest  in 
processing  power  rather  than  execution  time. 

The  following  observation  tells  us  the  range  of  execution  speed-up  we  can 
expect  from  a  semantic  transformation: 

Observation:* 

Let  the  degree  of  concurrency,  or  ■width,  T(T)  of  trace  set  T  be  the 

maximum  number  of  parallel  tines  in  any  trace  of  T.  T(7*)  is  the  execution 
time  of  T  as  defined  in  Sect.  5.1. 

Then,  for  every  trace  set  TeT  (SD)  generated  from  trace  set  T(S)  of 
some  refinement  S’  by  semantic  declarations  D  (without  idempotence), 

*  This  is  really  an  observation  about  individual  traces,  not  trace  sets.  But  we  are  here  pri¬ 
marily  concerned  with  trace  sets. 
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S  r (T)  z  T(T(S)) 

The  best  we  can  hope  for  is  that  T  maintains  its  maximum  degree  of 
concurrency  all  the  way,  dividing  the  length  of  T(S)  by  T(T).  In  other 
words,  the  execution  speed-up  of  the  refinement  by  trace  set  T  is  bounded 
by  the  degree  of  concurrency  of  T: 

^  r(T) 

Phrasing  it  more  loosely  (neglecting  constants):  to  save  some  order  of  exe¬ 
cution  time,  we  have  to  add  that  same  order  of  concurrency.  Take,  for  example, 
the  sorting  program  sort  n.  Its  sequential  execution  time  is  0  (n2)  (see 
Sect.  4.4).  A  concurrency  degree  of  0  (n)  improves  the  execution  time  to  0  (n) 
(see  Sect.  5.4). 

However,  the  order  of  execution  speed-up  may  fall  short  of  the  order  of 
number  of  processors  involved  in  the  execution,  unless  concurrency  is  main¬ 
tained  to  an  adequate  extent  throughout  the  execution. 

The  derivation  of  the  concurrent  from  the  sequential  trace  set  embodies 
the  additional  effort  we  have  to  expend.  This  is  part  of  the  concern  of  this 
chapter. 

We  also  have  to  describe  the  execution  of  the  concurrent  trace  set  we  arrive 
at.  Tn  the  operational  models  (Sect.  5.5)  we  view  the  execution  of  a  trace  set  as 
the  simultaneous  execution  of  all  its  traces.  For  an  implementation,  we  have  to 
be  more  realistic.  There  is  an  easy  implementation  for  any  refinement  S',  and 
therefore  also  for  its  trace  set  T(S).  But  we  will  have  to  restrict  the  effect  of 
semantic  declarations  in  order  to  keep  transformed  trace  sets  as  easily  imple- 
mentable. 

G.l  Trace  Seta 

This  section  discusses  the  selection  of  a  trace  from  some  trace  set  T  for 
refinement  S  for  execution. 


T(T(S)) 

T(T) 


-  64  - 


For  T(S ),  the  trace  set  of  S',  a  selection  is  easy:  if  S  does  not  contain  alter¬ 
natives,  there  is  only  one  trace,  and  for  every  alternative  IF  in  S,  the  trace  of 
T (IF)  to  be  executed  can  be  chosen  by  evaluating  the  guards  of  IF  in  any  order. 

Guard  evaluation  as  a  mechanism  for  trace  selection  works  only  if  the 
traces  containing  some  guard  of  IF  are  indistinguishable  up  to  that  guard.  In 
other  words,  trace  differences  must  always  originate  at  guards.  We  will  call  a 
trace  set  with  this  property  simple.  It  can  be  represented  by  a  tree  whose 
branches  originate  in  guards.  Each  path  form  the  root  to  a  leaf  of  the  tree 
corresponds  to  one  trace  in  the  set. 

For  every  refinement  S',  T(S)  is  simple.  However,  semantic  transformations 
may  introduce  non-simple  trace  sets.  Consider  the  following  situation: 

5 :  SO  ;  IF 

IF:  if  B1  ->  SI  d  B2  ->  S2  fi 
SO  &  B1  ,  SO  &  B2 

The  trace  sets  for  iS1  in  this  semantic  version  are 

T1  =di  [SO  ~^>B1  ->S1  ,  SO  ^>B2  -?S2  \  =  T(S) 

T2  =df  \B1  ->S0  ->S1  ,  SO  -Z>B2  H >S2  \ 

T3  =dJ  |S0  ->B1  ->S1  ,  B2  ^>B2  $ 

T4  =df  [B1  — >  SO — >  SI  ,  B2 — SO — ^ B2  ^ 

T1  and  T4  are  simple,  but  T2  and  T3  are  not.  We  have  to  restrict  the  effect 
of  semantic  declarations  such  that  only  simple  trace  sets  can  be  generated. 

Restriction  I: 

Let  °  stand  for  any  binary  semantic  relation.  Consider  some  com¬ 
ponent  C,  and  guarded  command  Bk-*Sk  of  some  alternation  IF  with  n 
guarded  commands.  Consider  a  semantic  declaration  Zi  =dTC°Bi 
(i  =  l,...tn) . 

Then  we  may  apply  all  Zi  simultaneously  to  some  instance  of  IF,  but  if 
Zi  does  not  hold  for  some  i,  no  Zj  (j^i)  may  take  effect. 


-  65  - 


With  this  restriction,  all  guards  of  an  alternative  are  subjected  to  identical 
semantic  transformations  and  simpleness  is  preserved. 

If  we  apply  it  to  the  example,  T2  and  T3  are  eliminated.  And  withdrawing 
one  of  the  semantic  declarations  has  the  effect  of  withdrawing  both. 


6.2  Semantic  Transformation  of  Trace  Sets 

This  section  discusses  the  selection  of  a  trace  set  T  for  refinement  S’  from 
the  transformation  set  T(SD)  of  semantic  version  SD  for  execution. 

We  will  perform  most  of  the  trace  set  transformations  before  run  time.  An 
execution  in  the  specified  time  limit  must  be  guaranteed  before  run  time.  But 
we  will  also  during  execution  allow  final  touches  that  require  no  or  negligible 
additional  processing. 


6.2.1  Before  Run  Time 

If  we  represent  the  trace  set  T(S)  of  refinement  S'  as  the  computation  rules 
(CO)  to  (C5)  suggest  (Sect.  5.1),  T(S)  can  be  computed  in  time  linear  with 
respect  to  the  length  of  S. 

The  transformation  set  T(SD)  of  a  semantic  version  SD  of  refinement  S’  is 
recursively  enumerable  (Sect.  5.2).  However,  the  length  of  the  transformation 
sequence  that  generates  some  T  from  T(S)  may  be  immense  -  as  bad  as  the 
sequential  execution  of  S'  for  every  input. 

The  complexity  of  transformation  of  T(S)  is  governed  by  two  factors: 

(l)  The  number  of  traces  (the  cardinality  of  T(S)). 

The  cardinality  of  T(S)  grows  exponentially  with  the  number  of  alter¬ 
nations  in  5:  if  S  has  m  alternations  with  n  guards  each,  T(S)  contains  nm 


traces. 
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(2)  The  number  of  applicators  in  the  traces. 

The  number  of  transformations  of  a  trace  grows  exponentially  with  the 
number  of  applicators  in  that  trace:  n  applicators  generate  271—  1  traces, 
one  for  each  combination  of  applications. 

Here  is  some  advice  on  how  the  complexity  of  semantic  transformations  can 
be  reduced: 

(1)  To  mitigate  the  impact  of  a  large  number  of  traces,  avoid  declarations  that 
refer  to  components  inside  alternatives.  For  the  purpose  of  semantic 
transformations,  alternations  that  are  below  the  level  of  semantic  declara¬ 
tions  can  be  viewed  as  basic  statements:  their  alternatives  need  not  be  indi¬ 
vidually  transformed. 

In  Sect.  6.3  we  mention  a  class  of  sorting  programs  whose  declarations 
never  need  to  refer  inside  alternatives.  For  the  purpose  of  semantic 
declarations,  their  trace  sets  reduce  to  single  traces. 

(2)  Compilable  concurrency  must  be  the  result  of  finitely  many  semantic 
transformations.  The  following  restriction  cuts  T(SD)  down  to  finite  cardi¬ 
nality: 

Restriction  II: 

A  semantic  transformation  inside  a  recursion  may  only  be  per¬ 
formed  if  it  applies  identically  at  every  level  of  the  recursion,  and  then 
it  must  be  applied  at  all  levels  simultaneously. 

Then  T(SD)  is  finite,  because  all  applications  of  a  declaration  inside  a 
recursion  generate  together  at  most  one  transformation  T'  from  any  T  for 
5.  By  definition,  only  recursion  can  make  a  transformation  set  infinite. 

Weaker  restrictions  are  conceivable.  A  declaration  inside  a  recursion 
may  generate  any  finite  number  of  transformations  to  keep  T(SD)  finite. 
For  a  program  whose  fastest  trace  sets  are  not  within  a  finite  transforma¬ 
tion  set,  see  Sect.  7.1. 

Here  is  a  collection  of  commands  for  the  semantic  transformation  of  trace 


sets: 
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rule 

command 

semantics 

(Gl) 

discard  v 

drop  node  v 

(G2) 

commute  v  left/right 

swap  node  v  with  left/right  neighbour 

(G3i) 

ravel  v  left/right 

merge  node  v  and  its  left/right  neigh¬ 
bour  in  a  concurrent  command 

(G3ii) 

ravel  v  right  trace  1/2 

append  node  v  to  the  left  of  trace  1/2  of 

its  right  neighbour  (which  must  be  a 

concurrent  command) 

(G3  iii) 

ravel  v  left  trace  1/2 

append  node  v  to  the  right  of  trace  1/2 

of  its  left  neighbour  (which  must  be  a 

concurrent  command) 

Consider,  for  example,  the  transformation  sequence  which  generates  con¬ 
current  trace  rn  from  trace  rn  of  sort  n  (Sect.  5.4):+ 

n  i— 3  i-3-y 

;  [  ;  [  ;  commute  cs  i  —j  left  ;  ravel  cs  i-j  left  ]  ] 

i=3  j= o  1 

where  cs  i  is  the  node  representing  the  first  instance  of  component  cs  i  to  the 

right  of  the  node  currently  looked  at.  Thus  rn  can  be  derived  from  Tn  in  one 
left-to-right  pass  of  right-to-left  commutations  and  ravellings  in  time  0(n3) 
( 0  (n )  for  every  nested  for).  However,  a  bounded  number  of  transformations 
can,  if  we  permit  unbounded  input,  improve  the  execution  time  only  by  a  con¬ 
stant  factor,  never  by  a  degree  of  magnitude. 

To  make  improvements  of  orders  of  magnitude,  we  have  to  be  able  to  recog¬ 
nize  recursive  patterns  in  transformation  sequences  and  apply  them  to  the 
recursive  representation  of  trace  sets.  The  automatic  recognition  of  these  pat¬ 
terns  is  a  formidable  problem  and  beyond  the  scope  of  this  thesis.  Our  current 
alternative  is  human  intervention.  The  user  should  be  able  to  communicate 
recursive  patterns  in  trace  set  transformations  to  the  compiler.  One  way  of 
^  Ti=ri  for  i  =  1,  2.  Therefore  semantic  transformations  start  with  n  =3 
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doing  this  is  by  proving  lemmas  like  the  one  in  Sect.  5.4  and  feeding  the  com¬ 
piler  the  resulting  trace  sets.  We  might  be  able  to  perform  at  least  syntactic 
transformations  automatically,  e.g.,  discover  the  identities  for  r'n+ 1  and  TMn  +  i  of 
the  proof  in  Sect.  5.4.  Another  way  is  to  feed  the  compiler  a  parameterized 
transformation  sequence  like  the  previous  with  parameter  tl  for  sort  n.  It  would 
then  derive  the  transformed  trace  set  by  applying  this  transformation,  in  our 

case  to  Xn  (see  Sect.  5.4),  but  without  evaluating  the  recursion  parameter. 

Improvements  of  orders  of  magnitude  for  unbounded  input  are  a  strong 
requirement  -  too  strong  for  any  specific  application:  machines  will  always  be 
limited  in  their  storage  and  processor  capacity.  If  we  know  the  application  will 
never  deal  with  more  than  k  inputs,  say,  we  may  prefer  to  simply  execute  a 
transformation  sequence  without  worrying  about  recursion.  For  example,  a 
reduction  of  the  execution  time  of  a  frequently  used  sort  n  from  0  (n2)  to  0(n), 
n^k,  may  well  be  worth  expending  time  0(k3).  But,  knowing  that  there  is  a 
transformation  sequence  of  0(n3),  we  must  still  find  it.  The  easy  way  is  again  to 
let  the  programmer  specify  it,  but  then  we  may  as  well  use  the  supplied 
knowledge  of  recursion.  Without  recourse  to  the  programmer,  a  left-to-right 
pass  of  right-to-left  commutations  and  ravellings  works  for  sort  n,  and  looks  like 
a  reasonable  approach  for  other  programs  as  well.  But,  without  experimental 
data,  nothing  more  can  be  said. 


6.2.2  At  Run  Time 

Ideally,  we  would  like  to  resolve  all  semantic  declarations  statically,  before 
run  time.  But  the  right  choice  of  trace  set  may  depend  on  factors  which  are 
difficult  to  predict,  like  input  data  or  time  properties.  If  a  sufficient  execution 
time  is  already  guaranteed,  some  remaining  decisions  are  better  resolved  dur¬ 
ing  execution. 

According  to  our  experience  in  using  this  methodology  for  program 
development,  many  programs  contain  only  global  declarations.  The  most  likely 
breach  of  globality  is  an  enabling  condition  for  conditional  commutativity  or 
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independence.  An  enabling  condition  can  be  thought  of  and  implemented  as  a 
case  analysis  of  trace  sets.  If  the  condition  is  satisfied  the  according  transforma¬ 
tion  takes  effect;  otherwise  it  does  not.  If  both  alternatives  have  been  compiled, 
the  only  additional  operations  at  run  time  are  the  test  of  the  enabling  condition 
and  the  following  branch. 

The  only  run-time  technique  for  trace  set  selection  that  we  investigate  in 
detail  is  racing.  Assume  a  set  of  operations  that  are  independent  up  to  a  point 
determined  by  their  progress  relative  to  each  other.  Instead  of  having  the  com¬ 
piler  select  a  trace  set  based  on  predicted  execution  times,  wc  can  race  the 
operations  during  program  execution  to  their  point  of  dependence. 

In  RL,  such  a  situation  involves  independence  declarations  that  mutually 
exclude  each  other.  The  mutual  exclusion  of  semantic  declarations  is  to  be  dis¬ 
tinguished  from  the  mutual  exclusion  of  program  components.  A  set  of  semantic 
declarations  is  mutually  exclusive  if  the  application  of  any  one  declaration  in 
the  set  renders  the  other  set  members  unexploitable.  The  following  RL  program 
offers  a  possibility  to  race  components  A  and  B: 

S:  A  ;  B 
A:  A1  ;  A2 
B :  B1  ;  B2 

(1)  A  Sc  B 

(2)  A  \\  31 

(3)  B  |j  A1 

Imagine,  for  instance,  A  and  B  sharing  a  variable  in  their  second  com¬ 
ponent,  while  working  in  distinct  variables  in  their  first. 

Commutativity  (l)  makes  both  independence  declarations  (2)  and  (3) 
exploitable.  Rut  whenever  one  is  applied  the  other  cannot  be.  Note  that  (2)  and 
(3)  together  can  be  refined  to 
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(4)  A1  !!  B1 

(5)  A1  jj  B2 

(6)  A2  |j  B1 

A  race  of  A  and  B  makes  at  run  time  a  choice  between  the  mutually 

exclusive  declarations  (5)  and  (6):  start  A1  and  B1  in  parallel,  applying  (4);  if  B1 
terminates  first  continue  in  parallel  with  B2,  applying  (5);  if  A1  terminates  first 
continue  in  parallel  with  A2,  applying  (6).  In  the  described  program,  racing  A 
and  B  always  yields  an  optimal  execution: 

If  B1  is  faster  than  A 1,  trace  rl  =df  g -j  g  2  >  ~^A2  is  selected, 

if  A1  is  faster  than  B1,  trace  t2  =<u  <C^  >  — >  B2  is  selected. 

Their  execution  times  are: 

T  (rl)  =  max(T(i  1),T(B1  )+T  {B2  ))  +  A<>  +  T  (A2  ) 

T?1  =df  T(A1  )+Ao+T(A2)  if  T (B1  )^T {A1  ) 

=  l  Tf '  =„f  T(B1  )+T(B2)+A<>+T(A2)  if  T(A1  )£T(B1  ) 

T (t2)  =  max(T(A7  )+T(A2),  T(B1  ))  +  Ao  +  T(il2) 

Tf  =di  T(B1  )  +  A<>+T (B2)  if  T (A1  )^T (B1  ) 

T|'  =df  T(A  1  )+T(A2)+A<>+T{B2)  if  T(B1  )£T(A1  ) 

Because  rl  is  the  better  choice  if  B1  is  faster  thanA/, 

because  Yg^Yf*,  t2  is  the  better  choice  if  A 1  is  faster  than  B1 . 

In  more  complicated  situations,  racing  may  not  produce  an  optimal  execu¬ 
tion.  In  fact,  it  can  be  arbitrarily  bad.  Assume,  for  instance,  that  A  and  B  regain 
their  independence  at  some  point: 

6’ :  A  ;  B 
A:  A  1  \A2\A3 
B:  31  ;  32  ;  B3 


(1) 

(2) 

(3) 


A  &B 

A  |!  \B1,B3  | 
B  ||  \A1,A3] 
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If  B1  is  faster  than  A  7.  trace  rl  =61  <  Bl^>B2^  ->  <A2  ^A3  >  is  chosen, 

if  A1  is  faster  than  B1,  trace  r2.  =df  <A1  J^A2  >  ->  <  B3>  is  chosen. 

If  we  take,  for  example,  the  following  execution  times  for  .4  and  B, 

T(A1)=2  T(A2)  =  1  T(A3)  =  20 

T(B  1  )  =  1  T (B2  )  =  20  T (B3 )  -  1 

sequential  execution  takes  45,  trace  rl  42,  and  trace  r2  24  time  units.  A  race 
would  select  rl  because  B1  is  faster  than  A1 ,  achieving  almost  none  of  the 
speed-up  that  is  possible.  Of  course,  the  long  operation  B2  on  shared  data 
should  be  in  parallel  with  the  long  independent  tail  component  A3. 

Racing  does  not  work  here  because  the  execution  time  of  only  the  initial 
independent  parts  of  A  and  B  are  determining  the  selection.  For  components 
which  gain  or  regain  independence  after  a  period  of  dependence,  methods  with 
look-ahead  are  required.  But  this  may  be  too  costly  at  run  time. 


6.3  Example:  Sorting  (Networks) 

For  the  purpose  of  semantic  transformations,  we  were  able  to  interpret  the 
trace  set  of  refinement  sort  7 1  (Sect.  2.3)  as  a  single  trace  (Sect.  5.4).  Knuth 
calls  sort  n  a  sorting  network.  A  sorting  network  is  a  sorting  refinement  with  a 
"homogeneous  sequence  of  comparisons,  in  the  sense  that  whenever  we  compare 
Ki  versus  Kj,  the  subsequent  comparisons  for  the  case  Ki<Kj  are  exactly  the 
same  as  for  the  case  K{>Kj  ,  but  with  i  and  j  interchanged"  [KnuIII].  The  alter¬ 
nations  in  such  refinements  are  hidden  inside  comparator  modules  (in  sort  n 
they  are  the  components  cs  i)  which,  when  considering  concurrency,  can  be 
viewed  as  basic  statements.  For  the  purpose  of  semantie  transformations,  trace 
sets  for  sorting  networks  reduce  to  single  traces. 

Here  is  another  refinement  with  the  same  semantics  as  sort  n .  We  add 
semantic  declarations  for  similar  concurrency: 
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n 

other  sort  n :  \  S  i 

i  =  l 

5  0:  skip 

Si:  if  a[i-l]>ct[i]  then  swap  i  ;  5  i-1  fi 

swap  i:  £[i]:  =  a[i  — l];  a[i  —  l]:=a[i] ;  a[i]:=t  [i] 

(1)  A  jVi  — 1,2,1  + 1:  swap  i  |[  a[j  —  l]>a[t/ ] 
ij 

(2)  A  j*i  —  1:  swap  i  jj  swap  j 

i-j 

other  sort  n  has  the  same  order  of  execution  time  as  sort  ti:  0(n2)  for  the 
refinement,  0{n)  for  the  given  semantic  version.  The  exact  time  properties  of 
other  sort  n  are  better  than  those  of  sort  n:  other  sort  n  omits  obsolete  compari¬ 
sons.  But  it  is  not  a  sorting  network,  and  every  trace  must  be  transformed  indi¬ 
vidually. 

The  declarations  of  both  sort  n  and  other  sort  n  obey  restrictions  I  and  II. 


6.4  Trace  Machines 

In  this  section  we  describe  machines  that  can  execute  trace  sets.  The  exe¬ 
cution  of  a  well-formed  trace  set  differs  from  that  of  one  of  its  traces  only  by 
some  guard  evaluations  (see  Sect.  6.1).  Their  implementation  is  not  our  concern. 
We  are  more  interested  in  the  implementation  of  concurrent  commands.  We 
therefore  consider  "trace"  machines  rather  than  "trace  set"  machines,  building 
on  the  fundamental  work  of  Conway  [Con63]: 

Independence  relations  are  binary,  so  we  only  consider  binary  concurrency. 
Concurrent  commands  with  more  than  two  tines  could  be  faster  than  the 
according  nesting  of  binary  concurrent  commands,  but  we  will  not  concern  our¬ 
selves  with  this  optimization.  It  is  rather  trivial  on  both  the  language  and  the 
machine  level. 


We  keep  track  of  the  level  of  concurrency  in  a  trace  execution  by  way  of  a 


-  73  - 


concurrency  tree.  A  tine  r  appears  in  the  tree  at  the  time  of  its  execution.  When 

/ 

the  concurrent  command  of  tine  r  is  executed,  rl  and  t2  appear  as 

sons  of  t.  A  tine  counter  identifies  the  concurrent  command  and  records  the 
progress  of  its  execution.  The  counter  is  shared  by  all  tines  of  the  concurrent 
command. 

The  program  trace  can  be  viewed  as  an  isolated  tine  and  builds  the  root  of 
the  tree.  It  is  linked  to  a  tine  counter  that  records  the  progress  of  the  call.  The 
concurrency  tree  expands  as  follows: 

(1)  At  the  time  of  program  call,  the  program  trace  is  established  as  root  and 
linked  to  an  external  tine  counter  with  value  1. 

(2)  On  initiation  of  a  concurrent  command  <  ^  >  in  trace  r,  rl  and  t2  are 
appended  to  t  and  linked  to  a  shared  tine  counter  with  value  2. 

(3)  On  termination  of  a  tine,  the  tine  counter  linked  to  it  is  decremented.  A 
zero  tine  counter  indicates  termination  of  the  according  concurrent  com¬ 
mand. 

We  can  implement  this  mechanism  in  a  straight-forward  manner: 

We  assign  one  processor  to  each  tine.  To  start  its  execution,  wre  provide  the 
processor  with  the  tine’s  starting  address  and  a  link  to  a  tine  counter.  A  con¬ 
current  command  is  executed  by  setting  up  a  tine  counter  and  starting  its  exe¬ 
cution  of  the  tines  on  different  processors.  Decrementing  a  tine  counter  to  0 
resumes  the  execution  of  the  tine  that  contains  the  concurrent  command. 

This  implementation  can  be  canonically  mapped  on  a  configuration  of  distri¬ 
buted  processors  without  shared  memory  and  with  message  passing  as  commun¬ 
ication  device.  Every  variable  is  stored  with  the  processor  assigned  to  the  tine  in 
which  the  variable  is  introduced,  with  the  assumption  that  this  is  the  smallest 
program  part  containing  all  tines  that  share  the  variable.  During  the  execution 
of  the  concurrent  command,  the  processor  that  initiated  it  has  to  be  available 
for  communication  with  the  units  processing  its  tines  ,  in  case  they  access 
shared  variables.  (It  may  be  fastest  to  pass  copies  of  the  shared  variables  for 
local  update  to  the  tines  and  let  them  report  changes  back  at  their  termination. 
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The  change  v'  of  a  concurrent  command  <C  ^  on  a  global  variable  with  value 

v  passed  to  rl  and  t2  can  then  be  synthesized  by  calculating  v'  =v1  +v2  —  v  , 
where  vi  is  the  value  passed  back  by  ri). 

The  static  assignment  of  processors  to  tines  is  fast  and  simple,  but  uses 
unnecessarily  many  processors:  one  for  each  node  in  the  concurrency  tree.  The 
maximum  number  of  parallel  computations  is  the  number  of  leaves  in  the  tree. 
We  can  optimize  the  utilization  of  processors  by  reassigning  processors  between 
tines: 

(1)  At  the  time  of  program  call,  some  free  processor  is  selected  to  start  exe¬ 
cuting  the  program  trace. 

(2)  On  encountering  a  concurrent  command,  a  processor  requests  the  selection 
of  two  free  processors  for  execution  of  its  tines  and  deactivates  itself. 

(3)  At  termination  of  a  tine,  the  executing  processor  deactivates  itself  but,  in 
case  that  the  concurrent  command  is  terminated,  only  after  a  request  to 
let  some  free  processor  continue  the  execution  of  the  tine  containing  the 
concurrent  command. 

A  special-purpose  processor,  the  dispatcher,  handles  requests  for  processor 
activation. 

This  implementation  is  not  appropriate  for  use  on  a  distributed 
configuration  because  that  would  imply  swapping  of  a  tine’s  environment  at  each 
processor  reassignment.  It  can  be  better  mapped  on  a  centralized  configuration 
with  shared  memory: 

Assume  a  cache-like  paging  mechanism  for  the  assignment  of  memory 
modules  to  processors.  Potentially,  each  processor  can  own  any  module. ^  Store 
the  trace  such  that  independent  tines  occupy  discrete  modules.  With  each  tine 
ail  its  data  and  only  its  data  are  stored.  A  processor  assigned  to  a  tine  may 
access  the  modules  the  tine  occupies.  Since  it  cannot  look  at  global  data,  the 
copying  scheme  described  previously  for  the  distributed  configuration  has  to  be 
^  Convray  describes  such  a  mechanism  [Con63]. 
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adopted.  Presumably,  access  of  global  data  means  shared  access  of  a  memory 
module.  The  described  mapping  abolishes  shared  access.  Processors  executing 
in  parallel  will  be  assigned  distinct  modules. 

If  we  drop  the  copying  scheme  and  allow  a  processor  to  look  also  at  modules 
which  contain  data  not  local  to  its  tine,  shared  accesses  are  a  possibility,  and 
prerequisites  of  the  used  non-interference  relation  have  to  be  enforced.  (We 
require  indivisibility  of  memory  reference.) 
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7  More  Examples 


At  this  point,  all  of  the  formalism  has  been  introduced,  but  several  aspects 
of  the  methodology  need  to  be  demonstrated. 

We  will  present  a  number  of  popular  examples  on  which  methodologies  and 
programming  languages  with  concurrency  are  usually  tested.  Unfortunately, 
people  are  often  more  interested  in  the  behaviour  of  such  programs  than  in  a 
result.  They  essentially  want  to  simulate  activities  of  concurrency,  synchroniza¬ 
tion,  and  scheduling.  Our  methodology  does  not  apply  to  simulation  -  we  do  not 
specify  behaviour.  But  we  can  express  the  desired  concurrency,  as  we  informally 
understand  it,  in  RI.,^ 

The  formal  treatment  of  the  examples  is  deferred  to  appendices.  We 
encourage  the  reader  to  look  at  them;  they  also  provide  new  clues. 


7.1  The  Sieve  of  Eratosthenes 

The  odd  prime  numbers  less  than  a  given  integer,  N,  are  to  be  determined 
by  rectifying  the  initial  assumption  that  all  odd  numbers  are  prime.  We  specify: 


sieve,  pre: 

/\  prime  [i  ] 

ic/ 

sieve,  post: 

/\  (  prime[i]  =  i  is  prime  ) 

ic/ 

where  /  {i\3£i<N,  ie. N,  i  odd^ 

This  is  a  second  "pure"  problem,  i.e.,  a  problem  which  is  fully  specified  by 
an  input/output  assertion  pair.  Our  program  follows  suggestions  of  Knuth 
[KnuII]  (for  a  proof  of  correctness  see  App.  A.2): 

'  Some  of  the  behaviours  are  caused  by  space  limitations  which  could  be  properly 
specified,  much  like  execution  time,  but  are  at  present  not  taken  into  account. 
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sieve:  ^  if  prime  [2i+  1]  then  elim  mults  of  2i  +  l  fi 

i^j 

elim  mults  of  i:  ;  prime  [i?'+2iji]:= false 

J'i  =  0 

(1) 

(2) 

(3) 


/\  i  : 
ii 

A  i*j: 
ij 

A 

i 


t  vt  i  l/O  I  v  J  • 


prime  [i  ]:  =  false  ||  prime  [j ]:=false 


!  prime  [i  ]:  =  false 


Any  pair  of  tests  and/or  eliminations  of  different  numbers  is  independent; 
any  test  or  elimination  of  a  number  is  idempotent.  (Remember  that  guard 
independence  and  idempotence  need  not  be  declared.) 

According  to  the  semantic  declarations,  guard  pj~ime[j]  and  statement 
elim  mults  of  i  are  independent  unless  j  happens  to  be  a  multiple  of  i.  Thus  the 
order  of  execution  of  prime  [j  J  and  elim  mults  of  i  may  only  be  manipulated  if  j 
is  not  a  multiple  of  i:  transformed  computations  must  maintain  an  order,  intro¬ 
duced  by  the  refinement,  in  which  guard  prime  [j  J  appears  only  where  its  truth 
ensures  that  j  is  prime.  In  other  words,  no  computation  will  call  elim  mults  of  i 
for  non-prime  i.  Moreover,  because  of  idempotence,  there  are  computations 
which  eliminate  every  multiple  exactly  once. 

The  execution  time  of  refinement  sieve  is  exponential  in  the  input  N.  The 
fastest  computations  for  the  present  semantic  version  have  an  execution  time 
constant  in  N:  the  time  it  takes  to  eliminate  one  multiple.  Multiples  are  the 
index  values  of  the  second  for  loop.  Their  calculation  is  disregarded  in  the  pro¬ 
perties  of  sieve  but  is  also  of  constant  time,  at  the  expense  of  exponential 
space/  (Y/e  agreed  to  initiate  a  for  loop  with  the  concurrent  calculation  of  all  its 
index  values;  see  Sect.  4.2.1.) 


^  Other  time/space  relationships  have  to  be  coded  explicitly  in  a  recursive  refinement. 
The  sieve  presented  in  [LerleOl]  runs  in  0(N)  space  and  0(N )  time  by  allowing  for  con¬ 
current  elimination  of  multiples  of  different  primes  but  requiring  sequential  elimination  of 
multiples  of  the  same  prime. 


-  76  - 


One  purpose  of  this  example  is  to  demonstrate  how  difficult  optimum  con¬ 
currency  can  be  -  even  when  derived  from  simple  semantic  declarations. 

In  this  version  of  sieve  there  is  no  hope  for  optimum  concurrency.  To 
derive  fastest  computations  for  every  input  n,  all  multiples  would  have  to  be 
known  -  which  makes  the  execution  of  sieve  obsolete.  Moreover,  there  is  no  way 
to  find  all  multiples  other  than  by  infinite  enumeration. 

But  we  can  compile  sieve  with  limited  concurrency.  We  know,  for  instance, 
that,  if  the  multiples  of  the  first  m  primes  have  been  eliminated,  the  ra  +  lst  and 
m  +  2nd  element  left  in  /  must  be  prime:  the  m  +  lst  certainly  is,  the  m+2nd 
must  be  because  between  a  prime  and  its  first  multiple  there  is  always  another 
prime.1”  Therefore  operations  elim  mults  of  i  can,  with  increasing  i,  at  least 
proceed  pairwise  in  parallel. *  * 

We  leave  it  up  to  the  number  theorists  to  find  more  compilable  con¬ 
currency.  The  trouble  with  prime  numbers  is  that  there  are  many  properties 
that  can  only  be  proved  with  some  margin  of  uncertainty.  Such  properties  may 
be  useful  if  taking  a  multiple  for  prime,  once  in  a  while,  does  not  hurt.  However, 
for  this  sieve,  they  are  of  no  help.  As  pointed  out  previously,  the  refinement 
detects  primes  with  certainty,  and  our  calculus  does  not  tolerate  semantic  devi¬ 
ations  due  to  concurrency. 


7.2  The  Dining  Philosophers 

Five  philosophers,  sitting  at  a  round  table,  alternate  between  eating  and 
thinking.  When  a  philosopher  gets  hungry,  he  picks  up  two  forks  next  to  his 
plate  and  starts  eating.  There  are,  however,  only  five  forks  on  the  table,  one 
between  each  two  philosophers.  So  a  philosopher  can  only  eat  when  neither  of 
his  neighbours  is  eating.  When  a  philosopher  has  finished  eating,  he  puts  down 
his  forks  and  goes  back  to  thinking. 


1  Bertrand's  Postulate  [HaWr0O] 

*  For  a  process  program  exploiting  this  fact  see  [Hoa75]. 
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This  example  demonstrates  how  the  methodology  can  be  used  to  build 
never-ending  algorithms.  That  is  the  only  point  we  want  to  make  in  this  section. 
A  full  formal  treatment  of  the  program  modelling  the  five  philosophers  can  be 
found  in  App.  A. 3. 


Our  methodology  can  only  yield  terminating  refinements.  Therefore  we 
modify  the  problem  specification  and  give  the  philosophers  a  finite  life  of  N 
meals  (allowing  different  philosophers  individually  many  eating  sessions  is  a 
trivial  extension): 

lives,  pre:  all  forks  are  on  the  table 

lives,  post:  all  forks  are  on  the  table,  and  every  philosopher  has 

eaten  exactly  N  times  in  this  life 

We  represent  the  philosophers'  actions  by  statements  upi  and  doum^  for  a 
movement,  i.e.,  seizure  and  release  of  fork  i,  eati  for  an  eating  session,  and 
thinks  for  a  thinking  period  of  philosopher  i  (for  their  refinements  see  App.  A.3).T 


N  4 


lives :  ;  [  ; 

phili  ] 

O 

II 

V 

1 

ri 

phili :  upi ;  upi#! ;  eati  ;  dovjn^  ;  dcm^01 ; 

(1) 

A  j*i: 

<3 

phili  Sc  philj 

(2) 

A  j *i©l,i,i©l: 
ij 

eati  !!  eatj 

(3) 

ea^  |j  [up,  douin]j 

(4) 

A  j *i: 

[up,  dvum]i  ||  [up,  dou/Ti]j 

(5) 

A  j*i: 

thinki  |!  philj 

This  program  lets  philosophers  properly  compete  for  their  share  of  the 
meal  and  eventually  die.  The  declarations  state  that  philosophers  may  eat  at 
different  intervals  according  to  their  hunger  (l),  non-neighbours  may  eat  at  the 
same  time  (2),  forks  that  are  presently  not  used  for  eating  may  be  moved  (3), 


!  ®  denotes  addition,  ©  subtraction  modulo  5. 


-  80- 


difFerent  forks  may  be  moved  in  parallel  (4),  and  thinking  philosophers  do  not 
interact  with  the  rest  of  the  system  (5). 

The  total  correctness  of  the  refinement  (see  App.  A.3)  guarantees  that  the 
system  cannot  get  stuck.  None  of  the  five  semantic  declarations  invalidates  total 
correctness  (no  correct  declaration  ever  does),  and  therefore  the  concurrent 
version  is  also  deadlock-free.  We  do  not  need  additional  proof,  but  to  help  the 
reader  being  convinced,  here  is  a  reasoning  especially  tailored  for  this  algo¬ 
rithm:  a  situation  where  every  philosopher  has  one  fork  and  waits  for  the  other 
cannot  arise  because  in  the  refinement  philosopher  i  lets  no  neighbour  access 
the  forks  next  to  him  once  he  prepares  for  eating,  and  none  of  the  declarations 
permits  commutations  which  would  lift  this  restriction.  The  key  is  that  (3)  does 
not  commute  eating  sessions  with  the  movement  of  forks  for  neighbours. 

For  a  never-ending  program,  a  solution  to  the  infinite  problem,  the  finite 
lives  may  be  called  repeatedly  in  sequence.  The  user  of  our  finite  algorithms  is 
responsible  for  a  mechanism  for  infinite  repetition;  we  refuse  to  consider  it  in 
our  calculus.  But  we  guarantee  that,  if  the  problem  specification  allows  an 
infinite  repetition  of  the  solution  (i.e.,  if  the  output  assertion  implies  the  input 
assertion),  all  algorithmic  properties  except  termination  are  preserved.  The 
user  can  rely  on  partial  correctness,  absence  of  deadlock,  and  absence  of  star¬ 
vation  without  recourse  to  an  authority  outside  the  program,  e.g.,  a  fair 
scheduler. 

Our  solutions  may  be  slightly  more  restrictive  than  non-terminating  solu¬ 
tions  have  to  be.  We  do  not  allow  unbounded  non-determinism,  not  even  for 
unbounded  activities.  In  this  example,  the  table  is  cleared  completely  in  arbi¬ 
trarily  long  intervals,  whereas  it  is  not  necessary  for  all  philosophers  to  leave 
(or,  in  our  terminology,  die). 

There  is  a  straight-forward  extension  to  our  calculus  which  lifts  this  restric¬ 
tion:  the  exploitation  of  semantic  relations  between  components  of  different 
calls  of  refinement  lives  must  be  allowed.  Then  a  call  of  lives  can  start  before 
the  previous  call  terminates.  Deadlock  remains  impossible,  but  to  prevent  star¬ 
vation  it  must  somehow  be  ensured  that  no  call  phili  is  commuted  to  infinity. 
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This  is  the  problem  of  "fair  scheduling",  which  we  shall  not  address. 


7.3  Producing  and  Consuming 


Suppose  that  two  parts  of  a  program  are  almost  distinct;  there  is  only  one 
variable,  buf,  which  appears  in  both.  One  part  "produces"  values  and  deposits 
them  into  the  buffer,  the  other  "consumes"  deposited  values  by  reading  them 
from  the  buffer.  The  following  program  fragment  reflects  this  situation.  Produc¬ 
tions  and  consumptions  are  called  in  turn  M  times;  the  omitted  expressions  in 
the  assignments  represent  the  creation  of  item  i  in  production  i,  and  the  use  of 
item  i  in  consumption  i : 

M- 1 

stream :  ;  [  prodi ;  cons ,  ] 

i=0 

prodi :  buf :  = 

const'.  :=buf 


The  dependence  of  productions  and  consumptions  forces  an  execution  in 
sequence.  But  we  would  like  some  concurrency.  We  apply  the  independence 
theorem  (Sect.  4.3.1)  and  disconnect  different  prod/ cons  pairs  by  giving  every¬ 
one  its  private  buffer.  Then  a  production  of  some  item  i  may  go  on  in  parallel 
with  the  consumption  of  other  items  j  produced  previously: 


(i) 


stream : 

M- 1 

;  [  prodi  I  consj  ] 

i=0 

prodi. 

buf[i]:= 

const'. 

:=buf[i] 

A  i*j : 

u 

prodi  ii  conSj 

We  did  not  specify  any  special  properties  of  productions  and  consumptions 
other  than  their  interaction  over  buf.  In  cases  where  the  creation  of  item  i  does 
not  depend  on  knowledge  of  items  0  to  i  —  1  productions  may  be  mutually 
independent,  and  similarly  may  be  consumptions.  Then  we  may  add  two  more 
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declarations: 

(2)  A  i*j:  prodi\\prodj 

(3)  A  i*j:  consi  |j  cotis.- 
U 

For  an  implementation  we  must  assume  a  bound,  say  n,  on  the  number  of 
variables.  We  modify  the  previous  program  by  indexing  the  buffer  modulo  n: 

u- 1 

stream. :  ;  [  prodi ;  co7is«-  ] 

i=0 

prodi’.  6u/[i  modn]:  = 
cons*:  : = buf  \_z  mod n  ] 

A  (x^j)modn:  prodi  II  conSj 

A  (i^j)modn:  prodi  prod* 

i.i 

A  (i*  j )  modn:  consi  |j  cons * 
ij 

Concurrency  works  only  for  prod/ cons  pairs  within  a  certain  neighbour¬ 
hood.^  productions  can  be  at  most  n  items  ahead  of  consumptions,  then  the 
buffer  is  full;  consumptions  can  at  most  catch  up  with  productions,  then  the 
buffer  is  empty.  Note  that  the  condition  "buffer  empty"  is  part  of  any  program 
with  producing  and  consuming,  whereas  "buffer  full"  arises  out  of  a  need  for  a 
buffer  bound  in  an  implementation. 

The  outcome  of  this  section  is  nothing  new.  The  solution  to  concurrent  pro¬ 
ducing  and  consuming  is  well-known.  But  we  wanted  to  exhibit  its  stepwise 
development  in  our  methodology  and  tried  not  to  rely  on  previous  knowledge. 


(1) 

(2) 

(3) 


*  More  independence  is  declared  but  not  exploitable. 
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8  Conclusions 


8.1  Summary 

We  take  the  view  that  concurrency  is  a  property  not  of  programs  but  of  exe¬ 
cutions.  Consequently,  looking  at  programs,  parallelism  may  be  hard  to  recog¬ 
nize.  RL  programs  do  not  contain  concurrent  commands  or  synchronization 
primitives,  only  declarations  of  independence.  And  because  an  independence 
declaration  may  remain  unexploited  it  only  suggests  that  some  action  may  or 
may  not  be  involved  in  a  parallel  execution. 


The  reader  might  feel  that  starting  with  the  definition  of  processes  helps 
structuring  a  program,  and  that  a  refinement  without  immediate  regard  to  con¬ 
currency  forces  us  to  artificially  order  logically  separate  tasks.  We  believe  there 
is  a  separation  of  concerns:  modularity  structures  the  problem  solution,  con¬ 
currency  speeds  its  execution  up.  For  example,  an  airline  reservation  or  taxi 
dispatching  system  receives  its  structure  from  the  modularity  of  its  transac¬ 
tions.  It  can  well  be  imagined  as  an  arbitrary  sequence  of  transactions  (in  fact, 
this  view  will  be  helpful),  although  only  a  concurrent  execution  will  be  practical. 

Our  methodology  yields  modularity  by  way  of  refinement  (as  part  of  the 
language!)  and  concurrency  by  way  of  semantic  declarations.  A  change  in  the 
refinement  is  likely  to  affect  the  semantic  declarations  for  it  (but  an  extension 
does  not).  Concurrency  works  bottom-up  and  is  therefore  susceptible  to  top- 
down  design  changes.  But  we  insist  the  solutions  are  modifiable.  They  only  put 
concurrency  in  its  proper  place:  determined  by,  not  determining  the  semantics 
of  the  refinement.  If  a  refinement  does  not  permit  enough  parallelism,  the 
independence  theorem  advises  to  spread  out  variables  over  its  components. 


Concurrent  actions  are  not  synchronized  by  conditional  delays  but  by  con¬ 
ditional  concurrency.  The  solutions  are  the  same  but  our  methodology  prevents 
overdefinition  and  subsequent  restriction  of  concurrency.  The  definition  of  con¬ 
currency  proceeds  step  by  step  on  semantically  correct  territory,  successive 
declarations  yielding  faster  and  faster  executions.  Exclusion  is  not  explicitly 
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programmed.  A  process  design  approaches  a  solution  from  incorrect  territory 
by  trying  to  exclude  wrong  concurrency. 

However,  the  concurrency  of  RL  programs  in  its  present  form  is  less  flexible 
than  that  of  process  programs.  RL  programs  are  not  asynchronous  as  are  pro¬ 
cess  programs.  Consider  the  process  program 

x:  =  0; 

cobegin  <x:  =  x  + 1>  ;  SI 
X/  S2  ;  await  <  x>0  -»  "use  x"  > 

coend 


where  SI  and  S2  use  distinct  variables  and  do  not  use  x.  With  execution  times 

T(x:=0)=l  T(x:=x  +  1)  =  2  T(S1  )  =  4 
T(x>0)  =  1  T("use  x")  =  2  T (S2)  =  3 

this  program  can  be  executed  in  at  best  seven  time  units.  (Note  that  the  condi 
tion  x>0  is  instantly  satisfied  when  tested.)  The  corresponding  RL  program, 


S’ :  x  :=0 ;  A  ;  B 
A  :  x:=x  +  l;  SI 
B:  S2\  "use  x" 

(1)  A  ||  S2 

(a)  b  II  si 

has  three  concurrent  traces, 


x  :  =  0 


x\-x  + 1 


< 


O  /  x:=x  +  l  \ 

x:  =  0  — >  ^2  X 


S1  > 
S2  — >  "use  x"  ' 


<  SI  > 
^ "use  x "  ^ 


x  :  =  0 


^  x:=x  +  1  —>  SI  \ 
^  S2  ^ 


use  x 


whose  executions  all  require  eight  time  units. 

The  reason  for  this  inoptimality  is  that  we  describe  the  semantics  of  RL  pro¬ 
grams  by  sequences  of  basic  RL  statements.  A  basic  statement  cannot  be  split 
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further,  e.g.,  between  two  concurrent  commands  as  this  example  requires.  To 
derive  an  optimal  solution  the  refinement  would  have  to  be  continued,  maybe,  to 
a  very  low  machine  level. 

In  our  methodology  proofs  do  not  require  auxiliary  variables  [0wGr76a, 
0wGr76b].  It  seems  auxiliary  variables  have  the  purpose  of  relating  the  histories 
of  concurrent  program  parts  that  have  been  proved  separately,  like  processes. 
In  our  programs  concurrency  is  not  synthesized  from  separate  histories. 

We  consider  only  programming  problems  with  results,  i.e.,  we  can  only 
derive  terminating  programs.  Infinite  repetition  is  a  mechanism  of  the  user 
environment  and  applies  only  to  entire  RL  programs,  not  their  parts.  Absence  of 
deadlock  is  guaranteed  by  the  total  correctness  of  the  RL  program,  and  the 
question  of  starvation  does  not  arise. 

We  do  not  permit  program  properties  to  vary  due  to  overlapped  execution. 
Consider  the  following  program  of  two  processes  whose  outcome  depends  on  the 
point  at  which  the  first  process  is  executed: 

cobegin  <x  :=  1>  //  do  <  x  =  0  -*  y  :=y  + 1  >  od  coend 

There  is  no  equivalent  in  RL  because  different  interleaved  executions  have 
different  properties.1- 

An  important  application  of  this  type  is  concurrent  garbage  collection  as 
described  for  a  LISP  environment  in  [Gri77,  D i j 7 8 J : 

Assume  a  program  part  mutation  i  producing  garbage,  and  a  collection  con¬ 
currently  appending  garbage  to  a  list  of  free  space.  In  a  process  program  the 
concurrency  of  mutation  i  and  collection  can  be  proved  as  long  as  we  expect 
afterwards  only  the  garbage  of  mutations  previous  to  i  are  collected.  But  in  RL 

the  corresponding  declaration 

’  Note  that  limiting  the  number  of  repetitions, 

do  k  times  <  x  =0  -»  y  :-y  + 1  >  od 
or  skipping  the  assignment  to  y, 

do  <x-0  -*  skip  >  od 

still  does  not  yield  programs  expressible  in  RL:  the  point  of  execution  of  X'.  —  l  determines 
both  the  partial  correctness  and  termination  of  the  do  loop. 
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mutation  i  |j/?  collection 

where  R  =df  garbage  of  mutations  previous  to  i  collected 

is  not  legal.  The  interleavings  of  mutation  i  and  collection  do  not  have  identical 
properties:  in  some  collection  will  pick  up  the  garbage  produced  by  mutation  i, 
in  others  it  will  not.  mutation  i  cannot  be  proved  commutative  with  collection’ s 
search  for  more  garbage.  The  process  program  works  because  there  the  out¬ 
come  of  guard  evaluations  may  vary  for  different  interleavings. 

Programs  whose  properties  vary  for  different  interleavings  are  messy. 
Including  them  into  RL  would  seriously  complicate  semantic  relations  and  the 
properties  of  concurrent  commands. 

Semantic  proofs  are  of  linear  complexity  with  respect  to  the  length  of  the 
program.  For  every  trace  set,  time  proofs  are  linear.  The  complexity  of  a  time 
proof  for  the  program  is  determined  by  the  effort  expended  on  finding  a  satis¬ 
factory  trace  set,  i.e.,  by  the  complexity  of  the  search  algorithm  and  transfor¬ 
mation  sequence  used,  or  the  comprehension  of  the  user  who  performs  the 
transformation  on  paper.  If  a  satisfactory  transformation  can  be  found  in  linear 
time,  the  entire  proof  of  the  program  is  linear.  Our  examples  are  sort  n  and  the 
Dining  Philosophers. 


8.2  Related  Research 

The  introduction  and  summary  relate  our  methodology  to  customary  pro¬ 
gramming  with  processes.  Throughout  the  thesis  we  refer  to  the  proof  methods 
for  process  programs  by  Owicki  and  Gries  [0wGr?6a,  0wGr76b].  These  methods 
are,  however,  not  concerned  with  program  development. 

The  view  of  programming  with  concurrency  closest  to  ours  is  taken  in 
[LaSi79],  Van  Lamsweerde  and  Sintzoff  use  a  concurrent  command  but  begin 
with  sequential  semantics.  Exclusions  may  be  removed  by  way  of  correctness¬ 
preserving  program  transformations  which  are  not  described  in  detail.  The  con¬ 
current  processes  are  guarded  commands  (transitions).  The  guards 
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(synchronizing  conditions)  make  any  order  necessary  for  correctness  explicit. 
Transitions  are  repeated  forever,  and  non-trivial  formal  techniques  are  neces¬ 
sary  to  prevent  deadlock  and  starvation. 

Broy  describes  the  semantics  of  concurrent  programs  by  correctness- 
preserving  transformations  but  elaborates  only  on  the  opposite  direction:  serial¬ 
izing  concurrent  statements  [Broy80].  The  transformations  exploit  a  simple  glo¬ 
bal  independence  relation. 

Idempotence  appears  in  [Heh80],  but  for  programs  with  traditional  con¬ 
currency  features  (concurrent  commands  and  synchronization  primitives).  The 
implementation  described  there  works  only  for  last-action  calls. 

Path  expressions  [FlHa76],  incorporated  in  the  specification  language  for 
concurrent  systems  COSY  [Lau79a]  and  recently  extended  to  predicate  path 
expressions  [And79],  reflect  an  approach  inverse  to  ours:  starting  out  with  com¬ 
plete  concurrency  one  declares  relations,  paths,  that  tighten  sequencing.  There 
exist  several  semantic  definitions,  one  with  transition  networks,  another  with 
vector  firing  sequences  somewhat  like  our  traces  [Lau79b].  But  since  no  quality 
distinctions  are  made  between  different  sequences,  there  is  no  selection  prob¬ 
lem.  As  a  specification  tool  path  expressions  do  not  come  with  a  proof  system. 

Jones  recognizes  the  lack  of  development  methods  for  programs  with  con¬ 
currency,  he  calls  them  "interfering  programs",  and  proposes  extensions  to  pre¬ 
vious  methodologies  for  sequential  programs,  what  he  calls  "isolated  programs" 
[Jon80].  The  basic  idea  is  to  incorporate  requirements  for  parallel  correctness 
into  the  problem  specification. 


fl.3  Further  Research 

One  goal  of  this  thesis  was  to  deduce  the  concurrency  in  a  program  from  its 
semantic  properties.  We  express  semantic  properties  in  the  weakest  precondi¬ 
tion  calculus  but  are  not  quite  satisfied  with  the  definition  of  the  most  difficult 
property:  non-interference. 
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It  is  evident  that  the  relation  <-)->  is  not  "a  simple  convention"  [0wGr76a]. 
Despite  its  syntactic  looks  it  is  a  semantic  condition,  for  example,  when  sub¬ 
scripted  variables  are  involved.  We  would  like  to  relate  non-interfcrencc,  as  all 
other  semantic  relations,  to  a  postcondition. 

free 

is  of  practical  relevance,  but  «-{-»  is  of  theoretical  interest.  We  know  that 
is  not  the  weakest  condition  for  non-interference  assuming  memory  interlock 

free 

on  variables.  But  can  <-}•*  still  be  relaxed? 

Our  list  of  semantic  relations  is  not  exhaustive.  For  example,  relaxing  the 
equivalences  in  the  weakest  preconditions  for  commutativity  to  implications 
yields  semi-commutativity  [Hoa75].  Full  semi-commutativity  and  semi¬ 
independence  are  defined  accordingly.  (Semi-idempotence  does  not  seem  very 
useful.)  For  a  program  with  semi-relations  semantics  become  an  execution- 
dependent  property.  The  refinement  represents  the  computations  with  the 
strongest  semantics.  We  know  only  S  \R\d  T\R]  for  every  transformation  T. 

We  have  discussed  the  Dining  Philosophers  and  derived  a  solution  with  cer¬ 
tain  limitations.  For  instance,  we  assign  each  philosopher  a  fixed  number  of  eat¬ 
ing  sessions  in  advance  and  do  not  allow  unbounded  non-determinism,  not  even 
for  unbounded  activities.  Just  how  seriously  our  methodology  constrains  the 
specification  and  solution  of  problems  like  the  Dining  Philosophers  or  the 
Banker’s  Algorithm  [Dij68,  Lau79a]  remains  to  be  clarified.  (We  have  developed  a 
Banker’s  Algorithm,  of  sorts.  It  is  not  part  of  this  thesis  but  may  subsequently 
appear  in  a  paper.) 

Our  programming  calculus,  as  it  stands,  assumes  a  centralized  machine 
architecture  (a  number  of  processors  with  shared  memory).  In  Sect.  6.4  we 
point  out  that  we  can  implement  RL  programs  on  distributed  machines.  The 
timing  calculus  can  even  account  for  speed  differences  of  processors.  But  to 
model  the  time  lags  of  inter-processor  communication  we  need  an  additional 
rule  for  inter-processor  assignments  which  has  the  semantics  of  language  rule 
(LB)  but  different  time  properties.  This  would  enable  us  to  represent  distributed 
computations.  Piowever,  a  methodology  for  programming  distributed  machines 
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should  make  a  behaviour-oriented  approach  and,  at  this  point,  our  methodology 
does  not.  We  tried  to  add  behaviour  specifications  [LeHe8l]  but  found  no  satis¬ 
factory  formalism  so  far.  Behaviours  are  much  more  complicated  than  semantic 
or  time  properties. 

However,  the  most  urgent  work  remains  to  be  done  on  the  implementation 
of  the  concept  of  semantic  declarations.  We  take  a  first  step  towards  formalizing 
a  methodology  that  incorporates  the  derivation  of  concurrency  rather  than  pos¬ 
tulating  the  existence  of  some  concurrency  situation.  This  thesis  provides  a  for¬ 
mal  semantic  model  but  is  rather  vague  on  its  implementation.  In  our  approach, 
the  hard  problem  is  the  compilation,  not  the  execution  of  the  program.  What 
algorithm  can  replace  the  intuition  of  the  programmer  in  the  search  for  a  suit¬ 
able  trace  set  and  still  be  of  acceptable  complexity? 


8.4  On  the  Purpose  of  Programming  Methodologies 

One  problem  of  formal  semantics  and  verification  is  that  even  simple  and 
seemingly  obvious  programs  have  lengthy  and  complicated  proofs.  Our  program¬ 
ming  methodology  has  been  demonstrated  on  a  set  of  simple  "toy"  problems. 
But  the  complexity  of  their  formal  treatment  may  give  rise  to  the  conclusion 
that  we  are  unable  to  cope  with  larger,  more  realistic  problems.  The  purpose  of 
this  section  is  to  alleviate  such  scepticism. 

Understanding  the  properties  of  a  program  to  the  last  detail  is  a  very 
strong  requirement.  A  programming  methodology  is  expected  to  adhere  to  it, 
and  this  adherence  has  to  be  demonstrated  on  examples  which  represent  a  class 
of  common  problems  but  are  small  enough  to  serve  their  tutorial  purpose. 

Verifying  realistic  applications  to  the  last  formal  detail  is  a  complex  and 
tedious  task  which  is  always  desirable  but  only  feasible  when  the  reliability  of 
the  solution  is  urgent  enough  to  justify  the  expense. *  Every  program  must  be 

^  One  would  hope  that  automatic  verification,  if  it  can  be  made  practical,  will  cut  the  ex¬ 
pense  drastically. 
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provable,  but  a  full  proof  should  not  be  demanded  in  every  case. 

Often  only  the  crucial  parts  will  receive  a  formal  treatment;  the  rest  will  be 
derived  with  some  degree  of  informality.  And  although  there  is  no  guarantee 
that  informally  derived  program  parts  are  totally  reliable,  a  methodology  should 
raise  confidence  that  they  will  work  sufficiently  well.  (The  permitted  margin  of 
unreliability  might  determine  the  degree  of  informality  in  the  program’s  deriva¬ 
tion.) 

We  shall  now  argue  that  our  methodologj^  works  for  both  formal  and  infor¬ 
mal  program  development: 

For  every  program,  (actually,  for  every  trace  set),  its  precise  properties 
are  expressed  by  weakest  preconditions  with  respect  to  any  postcondition. 
Examples  are  the  programs  fact  n  (App.  A.l)  and,  for  semantic  properties  only, 
sieve  (App.  A. 2)  and  sort  n  (Sect.  4.4). 

If  a  weakest  precondition  is  too  hard  to  obtain,  less  will  do  as  long  as  the 
problem  specification  is  shown  to  be  satisfied.  Then  the  effects  of  the  program 
are  only  known  in  environments  described  by  this  specification.  An  example  is 
the  derivation  of  only  a  worst-case  execution  time  for  program  sort  rc  (Sect.  4.4). 
For  other  than  worst-case  inputs,  the  exact  execution  time  remains  unknown. 

An  always  complex  wreakest  precondition  is  that  of  full  commutativity:  its 
derivation  takes  time  proportional  to  the  product  of  the  lengths  of  the  operands. 
We  cope  with  that  difficulty  by  applying  the  concept  of  globality  and,  in  the  sim¬ 
plest  cases,  employing  the  independence  theorem.  The  majority  of  indepen¬ 
dence  declarations  will  follow  from  the  independence  theorem  and  will  not 
require  a  quadratic  proof.  We  suggest:  the  user  has  to  pay  for  complicated  pro¬ 
grams  (here,  for  subtle  concurrency). 

One  could  be  contented  with  a  less  formal  idea  about  the  properties  of  a 
solution  or  even  have  only  an  informal  picture  of  the  problem.  Stepwise 
refinement  is  a  fundamental  and  long-established  method  for  careful  informal 
program  development.  The  same  idea  applied  to  the  discovery  of  concurrency  in 
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a  program  yields  stepwise  semantic  declarations.  Each  declaration  cam  be 
understood  in  isolation  and  most  declarations  will  be  clear  and  simple.  We 
presented  two  informal  problems  and  their  solutions  (Sects.  7.2  and  7.3),  and 
appended  the  formal  work  for  one  of  them  as  a  demonstration  that  our  intui¬ 
tions  were  correct  (App.  A.3).  We  believe  that  even  a  program  with  considerable 
proof  length  can  in  our  methodology  be  simple  on  an  informal  basis. 
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A  Appendix:  Formal  Treatment  of  Programming  Examples 

A.1  The  Factorial  Program 

We  are  interested  in  the  properties  of 

factn :  if  n  =  0  >  r  :  =  1 

(|  n>0  ->  fact  n  —  1;  r\—rn 

fi 


where  T(r-n)=l,  A._=A1f=Acal]=0 ,  and  T(n)=T(n  =  0)=T(n >0)=T(l)=T(fc )=0 . 
k  being  the  actual  index  of  the  call. 


Lemma: 


t  clock 

fact  k  (R  |  =  kSO  A  Rkhclock_k 


Proof: 


We  need  inductive  approximations  ( fact  A:)*. 

Base:  {fact  k  )o|/?  j  =  false 

For  clarification,  here  is  the  first  non-trivial  approximation: 

r  n 

(factk)i\R  |  =  (  n=0A  R  ^  V  n>OA  false  )  ^ 

S  fc=0  A 


in d.  hyp.:  {factk)i\R\  =  0^k<i  /\  R 


r,  clock 
k !,  clock— k 


ind.  step:  {fact  k  )i  +  i\R  |  =  (  n=OA/?^  V 


71 


7" 

n>0A(fact  n-l)4 cl~ck_x\  )k 

=  A;=OA/^  V  A;>OA[O^A;  — 1  <i 

r,  clock  r,  clock 

^  r '7i,  clock  —  1  ^  {k  —  l)!,  clock  — {k  —  1) 

r,  clock 

~  0^A;<2  +  1A  Rkl iCiock-k 


fact  k  [R  ] 
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r,  clock 

k~°  A  ^A;!,  clock -k 


=  V  {fact  k)i\R]  — 
t^o 

Corollary: 

For  positive  k,  call  fact  k  performs  k  multiplications. 

Proof: 

clock 

f  act  k  [clock  ^0]  =  kZ  0  A  (clock  ^0)  c^qc^_jc  =  (fc^O,  kZQD  clock^k  ) 

Thus,  as  function,  T(fact  k)  =  k  with  domain  k^O. 


A.2  The  Sieve  of  Eratosthenes 

A  proof  with  respect  to  specification 

sieve,  pre:  A  prime  [a  ] 

sieve,  post:  A  (  prime  [i ]  =  i  is  prime  ) 

where  /  = ^  [i\3£i<N,  ieN,  i  odd} 

is  easy:  by  assignment  rule  (L2),  the  semantic  weakest  precondition  of  sieve  is 
its  postcondition  with  all  occurrences  of  eliminated  positions  prime  [i]  replaced 
by  false.  Thus 

sieve  [ sieve,  post}  = 

A  (prime\i]  =  i  is  prime  )  A  A  (  false  =  i  is  prime  ) 

i€l\M  t€j/ 

where  M  =df  [n\n  £/,  V  V  n=i2+2ij  ] 

iel  j% o 

The  conjunct  over  M  is  true:  M  is  the  set  of  multiples  in  the  odd  numbers  I. 
Therefore  the  weakest  precondition  reduces  to 

sieve  £  sieve,  post}  =  A  prime  [i] 

l€/\,V 

sieve,  pre  D  sieve  [sieve,  post}  . 


such  that 


-97- 


A.3  The  Dining  Philosophers 

If  variable  eaten[i]  counts  the  meals  of  philosopher  i  and  variable  fork[i ] 
indicates  if  fork  i  is  currently  on  the  table  (fork[i]= 0)  or  not  (fork[i]> 0),  the 
semantic  specification  becomes: 

4 

lives,  pre:  A  fork  [i]=0 

i=0 

4 

lives,  post-  A  (/orfc’[i]=0  A  eaten'  \i]-eaten\i]^N  ) 

Resulting  values  of  fork  and  eaten  are  primed,  initial  values  are  unprimed. 

It  should  be  clear  that  the  following  refinements  of  the  philosophers’ 
actions  validate  all  five  semantic  declarations  globally  and  complete  the  lives  in 
conformity  with  the  semantic  specification: 

uPi:  /orfc[»]:=l 

downi :  fork\i\.  —  0 

eati.  use  fork  i  ;  use  fork  i©l;  eaten[i]:=eaten[i]  + 1 

thinki :  skip 

use  fork  i  is  an  operation  which  touches  variable  fork[i ]  but  has  no  effect, 
for  instance, 

use  fork  i :  if  fork[i]^ 0  -*  skip  fi 

The  resulting  RL  program  correctly  simulates  the  philosophers’  behaviour. 

We  presented  these  lives  in  Sect.  7.2  because  they  are  attractive  in  their 
simplicity.  But,  although  they  exhibit  the  correct  behaviour,  their  semantics  are 
not  adequate  for  the  following  reason: 

There  are  more  semantic  relations  which  we  did  not  declare  because  they 

generate  undesirable  behaviours.  For  example,  philosophers  do  not  have  to 

alternate  between  eating  and  thinking;  they  may  think  at  any  time  they  wish.  If 

we  look  at  the  declarations  as  program-specific  with  omitted  enabling  predicate 

A  fork[k]k0,  things  are  even  worse:  then,  by  dropping  the  qualifying  predicate 
k 
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in  (3),  a  philosopher  may  eat  whether  he  has  forks  or  not,  and  additional  weak¬ 
ening  of  the  qualifying  predicate  in  (2)  to  j  lets  neighbours  eat  at  the  same 
time.* 

A  model  with  adequate  semantics  should  permit  only  desirable  behaviours. 
We  will  strengthen  the  semantics  of  the  philosophers’  actions  such  that  they 
may  only  be  performed  when  the  forks  involved  are  in  a  proper  state.  Therefore 
different  users  of  the  same  fork  have  to  be  distinguished. 

Let  variable  fork[i ]  indicate  not  only  the  position  of  fork  i  but  also  which 
philosopher  j  is  holding  it,  if  any  {fork  [i  ]=j  + 1).  Let  subscripts  of  operations 
up,  down,  eat,  think  denote  strictly  philosophers,  and  identify  forks  by  super¬ 
scripts  relative  to  philosopher  i  (1  for  his  left  fork  i,  r  for  his  right  fork  i©l): 

N  4 


lives : 

;  [  ;  phili  ] 

1  t=0 

phili'. 

upl ;  upi  ;  eati ;  downl ;  down? ;  thinks 

up\: 

if  fork  [i  ]=  0  ->  fork  [i  ]:=i  + 1  fi 

up[: 

if  /orA;  [i6l]=0  -*  fork[i®l]:=i  +  l  fi 

down J: 

if  fork  [i]=i  +  l  ->  /orfc[2]:=0  fi 

down? : 

if  fork  [i©l]=i  + 1  -»  fork  [i©l]:  =  0  fi 

eatf 

if  fork  [i]=i  +  l  A  fork  [i®l]=x  +  l  -* 

use  fork  i  \  use  fork  i©l;  eaten[i]:=eaten[i  ]+ 1  fi 

thinkii 

if  fork[i j^x  +  l  A  fork[i(&l]*i  +  l  ->  skip  fi 

(1) 

A  j *i: 

phili  Sc  philj 

(8) 

A  j  *i\ 

eati  1!  Rn-tj 

*  This  illustrates  that  interpreting  declarations  as  program-specific  can  affect  their  ex- 
ploitability. 
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(3)  (a) 
(b) 


(5) 


A  j *i©l,i: 
A  j  *i,i®  1: 


t 

eati  ||  [up,  down]] 
eati  ||  [up,  down  jj 


AAA 

j  1,7  2 


A  j*i: 
ii 


*  1  k2 

.  fm  ml 

r  1 

3 1  3  2 

* U  if 

Li  101J 

{up,  doum]^1  ||  {lip,  down]j* 
thinki  ||  philj 


The  proof  of  the  refinement  with  respect  to  the  semantic  specification  and 
of  all  declarations  with  respect  to  the  global  scope  is  left  as  an  exercise  to  the 
reader.  Note  that  simultaneous  eating  of  neighbours  can  still  be  declared  but 
not  exploited  because  of  a  lack  of  forks  (2). 


University  of  Toronto 
Computer  Systems  Research  Group 


BIBLIOGRAPHY  OF  CSRG  TECHNICAL  REPORTS  I960  -  present 

*  -  Out  of  print 

*  CSRG- 106  DIALOGUE  ORGANIZATION  AND  STRUCTURE  FOR 

INTERACTIVE  INFORMATION  SYSTEMS 
John  Leonard  Barron 
[M.Sc.  Thesis,  DCS,  19e0] 

*  CSRG- 109  A  UNIFYING  MODEL  OF  PHYSICAL  DATABASES 

D.S.  Batory,  C.C.  Gotlieb,  ApTl  1980 

*  CSRG- 110  OPTIMAL  FILE  DESIGNS  AND  REORGANIZATION  POINTS 

D.S.  Batory,  April  I960 

*  CSRG-111  A  PANACHE  OP'  DBMS  IDEAS  Ill 

D.  Tsichritzis  (ed  ),  April  1980 

CSRG- 1 10  TOPICS  IN  PSN  -  IL  EXCEPTIONAL  CONDITION 

HANDLING  IN  PSN;  REPRESENTING  PROGRAMS  IN  PSN; 
CONTENTS  IN  PSN 

Yves  Lesperarice,  Byran  M.  Kramer,  Peter  F.  Schneider 
April,  1980 

CSRG- 113  SYSTEM-ORIENTED  MACRO-SCHEDULING 
C.C.  Gotlieb  and  A.  Schonbach 
May  1980 

CSRG- 114  A  FRAMEWORK  FOR  VISUAL  MOTION  UNDERSTANDING 
John  Konstantine  Tsotsos 
[Ph.D  Thesis,  DCS,  June  I960] 

CSRG- 115  SPECIFICATION  OF  CONCURRENT  EUCLID 
James  R.  Cordy  and  Richard  C.  Holt 
July  1980 

CSRG-116  THE  REPRESENTATION  OF  PROGRAMS  IN  THE 

PROCEDURAL  SEMANTIC  NETWORK  FORMALISM 
Bryan  M.  Kramer 
[M.Sc.  Thesis,  DCS,  1980] 

CSRG-117  CONTEXT-FREE  GRAMMARS  AND  DERIVATION  TREES  AS 
PROGRAMMING  TOOLS 
Volker  Linnemann 
September  1880 

CSRG-118  S/SL:  SYNTAX /SEMANTIC  LANGUAGE 
INTRODUCTION  AND  SPECIFICATION 
R.C.  Holt,  J.R.  Cordy,  D.B.  Wortman 
CSRG,  September  1980 


-2- 


CSRG-1 19  PT:  A  PASCAL,  SUBSET 
Alan  Rosselet 

[M.Sc.  Thesis,  DCS,  October  1980] 

CSRG-120  PTED:  A  SrANDARD  PASCAL  TEXT  EDITOR  BASED  ON 
THE  KERNIGHAN  AND  PLAUGER  DESIGN 
Ken  Newman,  DCS 
October  19B0 

CSRG-121  TERMINAL  CONTEXT  GRAMMARS 
Howard  W7.  Trickey 
[M.Sc.  Thesis,  EE,  September  1980] 

CSRG-122  THE  APPROXIMATE  SOLUTION  OF  LARGE  QUEUEING 
NETWORK  MODELS 
John  Zahorjar 

[Ph.D.  Thesis,  DCS,  August  1980] 

CSRG-123  A  FORMAL  TREATMENT  OF  IMPERFECT  INFORMATION 
JN  DATABASE  MANAGEMENT 
Yannis  Vassiliou 

[Ph.D.  Thesis,  DCS,  September  1930] 

CSRG-124  AN  ANALYTIC  MODEL  OF  PHYSICAL  DATABASES 
Don  S.  Batory 

[Ph.D.  Thesis,  DCS,  January  1981] 

CSRG-125  MACHINE-INDEPENDENT  CODE  GENERATION 
Richard  H.  Kozlak 
[M.Sc.  Thesis,  DCS,  January  1981] 

CSRG-126  COMPUTER  MACRO-SCHEDULING  FOR  HIGH  PRODUCTIVITY 
Abraham  Schonbach 
[Ph.D.  Thesis,  DCS,  March  1981] 

CSRG-12?  OMEGA  ALPHA 

D.  Tsichritzis  (ed  ),  March  1981 

CSRG-128  DIALOGUE  AND  PROCESS  DESIGN  FOR  INTERACTIVE 
INFORMATION  SYSTEMS  USING  TAXIS 
John  Barron,  April  1981 

CSRG-12S  DESIGN  AND  VERIFICATION  OF  INTERACTIVE  INFORMATION 
SYSTEMS  USING  TAXIS 
Harry  K.T  Wong 

[Ph.D.  Thesis,  DCS,  to  be  submitted] 

CSRG-130  DYNAMIC  PROTECTION  OF  OBJECTS  IN  A  COMPUTER  UTILITY 
I,esUe  H.  Goldsmith,  April,  1981 

CSRG-131  INTEGRITY  ANALYSIS  A  METHODOLOGY'  FOR  EDP  AUDIT 
AND  DATA  QUALITY  CONTROL 
Maija  Irene  Svanks 
[Ph.D.  Thesis,  DCS,  February  1981] 


-3- 


CSRG- 132  A  PROTOTYPE  KNOWLEDGE-BASED  SYSTEM 

FOR  COMPUTER-ASSISTED  MEDICAL  DIAGNOSIS 

Stephen  A.  Ho-Tai 

[M. Sc. Thesis,  DCS,  January  1981] 

CSRG-133  SPECIFICATION  OF  CONCURRENT  EUCLID 
James  R.  Cordy,  Richard  C.  Holt 
August  1981  (Version  l) 

CSRG-134  ANOTHER  LOOK  AT  COMMUNICATING  PROCESSES 
E.C.R.  Hehner  and  C.A.R.  Hoare,  July,  19B1 

CSRG-135  ROBUST  CONCURRENCY  CONTROL  IN  DISTRIBUTED  DATABASES 
Derek  L.  Eager 

[M.Sc.  Thesis,  DCS,  October  1981] 

CSRG-136  ESTIMATING  SELECTMTIES  IN  DATABASES 
Stavros  Chris  lodoulakis 
[Ph.D.  Thesis,  DCS,  December  1961] 

CSRG-137  SATISFYING  DATABASE  STATES 
Marc  H,  Graham 

[Ph.D.  Thesis,  DCS,  December  1981] 

CSRG-138  IMPROVING  THE  PERFORMANCE  OF  DATABASE  SYSTEMS 
Geovane  Cayres  Magalhaes 
[Ph.D.  Thesis,  DCS,  December  1981] 

CSRG-139  A  FORMAL  TREATMENT  OF  INCOMPLETE  KNOYiTLEDGE  BASES 
Hector  J.  Levesque 
[Ph.D.  Thesis,  DCS,  February  1982] 

CSRG-140  AN  OVERVIEW  OF  TUNIS:  A  UNIX  LOOK-ALIKE 
WRITTEN  IN  CONCURRENT  EUCLID 
R.C.  Holt,  February  19B2 

CSRG-141  ON  PROVING  THE  ABSENCE  OF  EXECUTION  ERRORS 
V.  David  Elliott 

[Ph.D.  Thesis,  DCS,  September  1980] 

CSRG-142  A  METHODOLOGY  FOR  PROGRAMMING  WITH  CONCURRENCY 
Christian  Lengauer 
[Ph.D.  Thesis,  DCS,  April  1982] 


